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PREFACE 


This manual describes the operation and use of GCOS communi- 
cations software for Honeywell-supported Series 60 (Level 6) 
communications devices and protocols. The term GCOS as used in 
the manual refers to GCOS 6 software. The term Level 6 refers to 
a specific series of Series 60 (Level 6) hardware models on which 
GCOS software is executed. 


Section 1 is a brief overview of GCOS software in general 
and itS communications subsystem. 


Section 2 summarizes the Monitor and file system macro.calls 
and services. | 


Sections 3 and 
COROT and FORTRAN 


Section 5 describes the use of communications in assembly 
language applications, using the GCOS file system interface. 


Section 6 deScribes the use of communications in assembly 
language applications, using GCOS physical I/O for more direct | 
access to data structures and physical devices. ~ 


Sections 7, 8, 9, and 10 describe the operation and use of 
Honeywell line protocol handlers for teleprinter-type (TTY), 
visual-information projection (VIP), polled VIP emulator (PVE) , 
and binary synchronous communication (BSC) device/protocols, 
respectively. > 


Appendix A provides more details about communications sSub- 
system functions. Appendix B contains tables of possible values 
for the STTY command and S$STTY macro call. Appendix C describes 
the system's resource control table (RCT), used as an interface 
between the software and the devices that use it. Appendix D 
contains various examples, intended for illustration only, of 
communications application programs for COBOL, FORTRAN, and 
assembly language. | 
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Appendix E lists communictions control characters and char- 
acter code sets. Appendix F lists the various device control 
characters and corresponding device keys. Appendix G describes 
how to obtain a dump of the multiline communications processor's 
(MLCP) and/or the dual communications processor's (DLCP) memory. 


How to Use the Manual 


The following are general guidelines to using the manual 
according to the reader's interests and responsibilities: 


Sections Applicable To: 
1 All users 
24, 3p: By 5 Applications programmerSs/analysts 


uSing higher-level languages 


6 Those responsible for system building; 
applications programmersS/analysts uSing 
assembly language 


7, 8, 9, 10 All users, but according to the device 
or protocol being used 


Appendix G All users. 


Remaining appendixes Users of corresponding numbered sections 


iii | CB03 


—_ 
AG 


MANUAL DIRECTORY 


The following publications comprise the GCOS 6 manual Set. 
The Manual Directory in the latest GCOS 6 MOD 400 Systems 
Concepts manual (Order No. CB20) lists the current revision 
number and addenda (if any) for each manual in the set. 


Order 
Number. Manual Title 
CBOl GCOS 6 Program Preparation 
CBO2 GCOS 6 Commands 
CB03 GCOS 6 Communications Processing 
CBO04 GCOS 6 Sort/Merge | 
CBO5 GCOS 6 Data File Organizations and Formats _ 
CB06 GCOS 6 Systems Messages eed 
CBO7 GCOS 6 Assembly Language Reference 
CBO08 GCOS 6 System Service Macro Calls 
CBO09 GCOS 6 RPG Reference 
CB10 GCOS 6 Intermediate COBOL Reference 
CB20 GCOS 6 MOD 400 System Concepts 
CB21 GCOS 6 MOD 400 Program Execution and Checkout 
CB22 GCOS 6 MOD 400 Programmer's Guide 
CB23 GCOS 6 MOD 400 System Guilding 
CB24 GCOS 6 MOD 400 Operator's Guide 
CB25 GCOS 6 MOD 400 FORTRAN Reference : 
CB26 GCOS 6 MOD 400 Entry-Level COBOL Reference 
CB27 GCOS 6 MOD 400 Programmer's Pocket Guide 
CB28 GCOS 6 MOD 400 Master Index 
CB30 Remote Batch Facility User's Guide 
CB31 Data Entry Facility User's Guide 
CB32 Data Entry Facility Operator's Quick Reference Guide 
CB33 Level 6/Level 6 File Transmission Facility User's Guide 


CB34 Level 6/Level 62 File Transmission Facility User's Guide 

CB35 Level 6/Level 64 (Native) File Transmission Facility 
User's Guide | | 

CB36 Level 6/Level 66 File Transmission Facility User's Guide 

CB37 Level 6/Series 200/2000 File Transmission Facility User's 
Guide 

CB38 Level 6/BSC 2780/3780 File Transmission Facility User's | 2% 
Guide i 8 


iv | CB03 


aes, 


Order 
Number Manual Title 
CB39 Level 6/Level 64 (Emulator) File Transmission Facility 
User's Guide | 
CB40 IBM 2780/3780 Workstation Facility User's Guide 
CB4] HASP Workstation Facility User's Guide 
CB42 Level 66 Host Resident Facility User's Guide 
CB43 Terminal Concentration Facility User's Guide 


The following documents provide general hardware 


information: 


Order 


Numbe 


AS 22 
ATO4 
AT97 
FQ4] 


r Manual Title 


Honeywell Level 6 Minicomputer Handbook 
Level 6 System and Peripherals Operation Manual 
MLCP Programmer's Reference Manual 

-Writable Control Store User's Guide 


Vv CBO03 


Section 1 


Section 2 


CONTENTS 


CommunicationS Overview ceccecccccses 
GCOS Software Overview wewcccccccecs 
GCOS 6 File System csrccrecccccces 
Physical Input/Output (Physical 
TIO ao wirwe aes: ah arand: ale oes Seow a. 
GCOS Communications Subsystem 
OVELV IEW. oh iis: o-6: ores bie 8 Serb 6 6 Se oe 
Communications SuperviSor .eecceee 
Line Protocol Handler (LPH) ..... 
Multiline Communications Pro- 
cessor (MLCP) and MLCP Driver . 
Communications Subsystem Interface 
With Applications Programs .... 
File System Interface ......e0. 
Physical Input/Output 
TH ECELACE? 6. os Sew Oe eee wes 
TTY and VIP Line Protocol Handler 
DEVICE SUPPOEE: Sse-dneee clere.e S 4.006% 
BSC and PVE Host-Communications 
DUDDOL CE: ssce.oe Sub, Sie.t6 ee 6 Sbinewe- 6.6 4r0e-ee 


File System Functions and Macro 
ROUCINGS:. s.6. 460s Gudae.0i4 6016s a eee ss 
File Management Macro Calls ....... 
Data Management Macro Calls ....... 
Storage Management Macro Calls .... 
File Information Block (FIB) ...... 

FIB Format and ContentS ........-. 
Program View Entry in the FIB ... 
FIB Displacement Definitions .... 
File System Considerations in 
COMMUNITCALIONS: -<-66.6 sss a6 6:64:65 sss 
Defining File/Terminal 
CHhavaCtCTiStlics «:scc.0s sm swe e esas 


vi 


NIN NM NM NN NH Do 
{ 
NOD WW PN EE 


CB03 


Tn 


Section 3 


Section 4 


CONTENTS (cont) © 


CommunicationS Via COBOL .....ccceeee 
Interactive Devices and Files ..... 
File System ConSiderationsS .......- 
Source Program Entries in 

COMMUNECATCIONS | 6:6% 6.06 d6:o06 8 68 owes 
Specifying Files in the Source 
PYOGLAM ceonenvecsesesesecscsece 
Use of ASSOC or GET Commands .... 
Assigning a File to a Device/ 
TEVMNINaD 56-6. eeb 6a eee eo Se 0 Se 
SELECT and ASSIGN Examples ...... 
Carriage CONRCLOL. 6-65 6st 6-04 e aw eee 
Printer Emulation .eccccccvccccce 
Specifying Asynchronous or 
Synchronous Read and Write 
BREGCULLON <7ii-Se0y 0264 eee Gees 
Synchronous Read and Write 
Operation (Call "ZCSYNC") ... 
Asynchronous Read and Write 
Operation (Call "ZCASN") .... 
WAIT for Completion -- 
Asynchronous Input and Output . 
Binary Synchronous Communication 
(BSC) WIth: COBOL: 460.0% s0e0 oe Soe 
BSC Data Transmission 
CONVENTIONS: : 6 6es 4.6 a0 o 6 eee ers 
BSC Data Code@S wenccccccccsee 
BSC Data Transmission Modes . 
BSC 2780 and BSC 3780 ....ee~ 
Macro Call’ Procedures for BSC 2780 
in Basic Transmission Mode .... 
Macro Call Procedures for BSC 2780 
in Advanced Data Transmission 
MOC 6 286 dce o-oo. eee ear beso e eee O26 bee 
Macro Call Procedures for BSC 3780 
in Advanced Data Transmission 


Mode BE grape ket A eee ae eee he, ws Suen, eee tt ae ee 


Communication Via FORTRAN ......eeeee 
Interactive Devices and Files ..... 
FORTRAN Program Execution With 

COMMUN1TCaE LOMS ~ 45.60 ieee aie ae ote ces 
Assigning Interactive Devices at 
EXCCUL VION: 3454080600 ees 6044464 
Changing Terminal's File 
ChavacteriSt ics). %.snwe.6-%. 426 aoe ewss 
FORTRAN File Status Check (ZFSTIN 
ONG. “ZESTOL). osc oedisisae-aine Sav here do 


vii 


Section 4 (cont) 


Section 5 


CONTENTS (cont) 


CALL Statement for ZFSTIN or 
BOLO sib 658 6 wo ca ae corete eae Rene ewer 

ZFSTIN and ZFSTOT Programming 
EXAM D1 CS: 20: scoai e806 aves 5 we ereveie/ eee 


Assembly Language Communications Using 
ENG File SyYStem wees ose wee se aeees.s 
File System Considerations ........ 
File-Processing Macro Calls in 


Assembly Language Applications .. 
Get File (SGTFIL) Macro Call 
GUIGELINGS 24.442 tes steno sess 
Open File (SOPFIL) Macro Call 
GUIGELINGS? c.6bis.206-b-ete ee Ss oe ees 
Test File (STIFTL, STOFTL\ Macro | 
Cal). GOIdELINGS: 44.4.4:s-64%25eeetes 
Wait File (SWIFIL, SWOFIL) Macro 
"Cald. -GUIGECLINGS® wed osha de ie%.e%s 
Device Dependent Macro Call 
PYOCGQULES. i265 Sieve a -eteee si: bee wee es 
Device Modes and Device Types ... 
Macro Call Procedures for Data 
Entry Terminal S.. os6 see Vek ete s wos 
Macro Call Procedures for Output 
Oniy Terminals: -c.60's:6sieseeere e868 


Macro Calis for a Single Inter- 


active Termindl «<6 <s8séssawsens 
Macro Call Procedures for Multiple 
Interactive TerminalS ....c.cccce 
Binary Synchronous Communication 
CBOC). %6-60-eiere-€ handed. woe 60 oe- ee oes 
BSC Data Transmission 
CORVGNE VON: osdbxey 4 koe ae ereerwe ots 
BSC. Data Codes: sis eis ewe scee 
BSC Data Transmission Modes . 
BSC 2780 and BSC 3780 .cccccececes 
Macro Call Procedures for BSC 2780 
in Basic Transmission Mode .... 
Macro Call Procedures for BSC 2780 
in Advanced Data Transmission 
MOdG> @5eS 66:64s Caw bere's-6 OSes 
Macro Call Procedures for BSC 3780 
in Advanced Data Transmission 


Mode @eeeeeeee34s535osseeseeeeee#e#etee®e#eeees @ 


viii 


CB03 


\ 
*. 


Section 6 


Section 7 


CONTENTS (cont) 


Assembly Language Communications 
Using Physical Input/Output ....... 
Communications Subsystem 

CONVENELONS. .<ieciis:s bed eee eee a ee 
Using Physical I/O éss%s0kss%~.<<.06-< 
Data. SUCLrUuCcturesS: .swé6 oe aswaw uw 2ee% 

Resource Control Table (RCT) .... 

Input/Output Request Block 

(TORB)..-. 6:0. océs6ve..b05 Sob S56 0s be aeons 
IORB Software Status Word 

(ESD: vars seventies lacie ataretetereis meas 

Communications Function Codes ..... 

Wait Online Function (Code 0) ... 

Write Function (Code 1) .ecccccees 

Read Function (Code 2) wccccccces 

Connect Function (Code A) ....... 

Disconnect Function (Code B) .... 

Requesting Communications. 

PUNCCIONS. «a6 s.0s sna eee es ce Sees 
Physical I/O Macro Calls for 
CONMUNLTCACITONS: o:60%.ccw's w ete Sowaw eck 


TTY Line Protocol Handler ...cccccces 
General TTY Line Protocol Handler 
ODELEE LOM. 266: oasis Sse eS 00 enw eee 
TTY MesSage FormatS ..cccccccvcece 
TTY Character Mode and Buffered 
Mode TYranSmiGS10On 44.%.6%.66:4 sees 
TTY. Character’ Mode: 6 6s-% os.és see's 
TTY Buffered Mode (VIP 7200 and 
TOOO)):: gate. 2 Sao cara eaten eee tus ane caeiei 
VIP 7200 and 7800 Hardware 
Switch Options With Character 
or Buffered Mode ..c.ccccccvcce 
VIP 7200 and 7800 Function and 
CONETOL: KEVS> sxécoieis sewers e-weteece 
TTY Line Protocol Handler Time-Out 
IN CELV G1GS. 6%. dw Sob ei6ecw we: 6:62 66s eee 
Using the TTY Line Protocol 
HANG LOE 16.6 exe: esos o-5 5. % we 4e. a woe See. 
TTY-Specific IORB Values ........ 
Control and Characteristics of TTY 
IWDGE DAES | 6 sic: 6%.6 ww wee ow 4 oe 
TTY Control Byte (Input) ...... 
TTY Nontransparent Input ...... 
TTY Transparent Input .....ceee 
TTY Line Feed (LF) and Carriage 
Return (CR) Input Sequence .. 


ix 


DADDAAHAND 
! 
hhh ro oO © 


Section 7 (cont) 


Section 8 


CONTENTS (cont) 


Keyboard Input Character and 

EI Ne “CONELOL.. ietste eee. darsre a eevee 
TTY Display of Input 

CRAVeCtErS, viictiwd sees Sous wees 
TTY Input in Buffered Mode 

(VIP 7200 and 7800 Only) .... 

Control and Characteristics of TTY 

OUEDPUC Data: sissies aso ae we ees 
TTY Control Byte (SEND) ....... 
End-of-Message (EOM) Sequence on 

TTY OUCDUt dss skies dae ae ee ee 
TTY Detection of BRK 

CHARACTCNS: sts gidieb ares wid be aie 
TTY Output in Buffered Mode ... 


VIP Line Protocol Handler ........c0.e 
General VIP Line Protocol Handler 
OPEGRGELON: i6:5:6.6-5:0. 9 5-6-o tie ow Se S we 
Software Functional Support for 
ENO VER esste goeitre aural ores eal ersieee. Saves 
User-Supplied Software Functions 
FOr VIP SUDPORE. 6 ase sleiaw- Sis-e-0'g aie 
VIP Time-Out IntervalS .......ee. 
Using the VIP Line Protocol 
HANG LCE 6% ears .8 eed enous aieeiece-« oe0e-e1e Ss 
VIP-Specific IORB ValueS .......-. 
VIP Polling Options <i6ie e660 éesce8 
VIP Poll Interval wwcscccceccee 
VIP Poll Duration (Time-Out) .. 
VIP Line Protocol Handler Poll 
BUNCE DONS: 6 Scsise:d ess ow See oa wo 68 
Control and Characteristics of VIP 
Input (Keyboard/Screen) ...eeee 
VIP Input Message Header ...... 
VIP Hardware Function Codes ... 
VIP Input Data wcccccccccccceves 
Control and Characteristics of VIP 
OUT UC seceita 6. 6e eres ie rereravee See el el ees 
VIP Output Message Header ..... 
VIP Control Byte (SEND) ....... 
VIP Output Data ccc eee cccces 
VIP Keyboard/Screen Output 
EGIEING CONtLO | - ecéevie. sce eis: ereece 
VIP Read-Only Printer Editing 
POCQUCNCE: 16-6756 wie deine 66-6 6 Sw eared 
VIP Read-Only Printer Form Feed 
DOCQGUCNCE 6.6:6-WS. os © 6. eee ee 6eAee ee 


CB03 


ails Bs 


CONTENTS (cont) 


Page 
Section 8 (cont) Error Processing by VIP Line 
Protocol Handler: ss: a:s 66 000-o100e-8:08 8-11 
Processing Nonpolled VIP Errors ... 8-14 
Section 9 Polled VIP Emulator (PVE) Line 
Protocol Handler sissies ase se stews 9-1 
General PVE Operation .cccrcccccecee 9-1 
Using the PVE Line Protocol 
HANGLEL <.6:6 6-6 ered. oxeerai eee ere. ee ewe & 288 9-2 
PVE-Specific IORB Values ........ 9-2 


VIP Protocol Message Structure for 
PV ee. cio ose ce Gis tes ay wc ene tee ae ee Ow are el 9-5 
Control and Characteristics of PVE 
TYNES 5 6.6ise: ivi Bowe) -are.tore WY ease ese ere ake ce 9-6 
PVE Input Message Header ...... 9-6 
PVE Hardware Function Codes ... 9-6 
PVE Input Data .ccrccccccccccvces 9-7 
Control and Characteristics of PVE 


OUT DUE. se wtecee 66 5S eos eee e si aee-e: ws S88 9-7 
PVE Output Message Header ..... 9-7 
PVE Terminal Address (ADR) and 

Message Status (STA) ........ 9-7 
PVE Output Data wccccscnssscsce 9-7 


PVE Line Protocol Handler Time-Out 


TIVE CU VES: seeds oom wee eo eee wane: eck sae 9-8 
Error Reporting by PVE Line Protocol 
HANGLE sige: 5S-sew Slee SS, See ete Sse aes 9-8 
Section 10 BSC 2780/3780 Line Protocol Handler . 10-1 
General BSC Line Protocol Handler 
OPeECAELON: -«swiaers ed 4a Seale wwe aie wees 10-1 
BSC Transmit and Receive 
ODEr At TONS: ods sw 65 6 ores ee oe eS 10-1 
BSC Data Transmission Modes ..... 10-2 
BSC Basic Data Transmission 
MOOG: 6.4 3-6-6 o-6' 6s oor S eh we baer ee 10-2 
BSC Advanced Data Transmission | 
MOOS o.oo eee sw: :5i- Salen te me wide eres eres 10-2 
BSC 2780 and BSC 3780 Differences . 10-3 
BSC 2780/3780 FeatureS ...cccccccce 10-3 
BSC Two~-Buffer Feature c.cccsecsee 10-3 
BSC Temporary Text Delay (TTD) 
FEATULS coccccesccncesecccsccce TO=5 
BSC Wait Before Acknowledge (WACK) 
FEQUCULE ©: \eoceerae oes Bo ee ee SS SS 10-6 
BSC Reverse Interrupt (RVI) 
BOQE UY ©. ..o: s Scsieorsos8 sre. ese Siete eo ere ese 10-7 


xi CBO03 


Section 10 (cont) 


Appendix A 


CONTENTS (cont) 


BSC End of Transmission (EOT) 


Feature 


eeeesecskeeeseeseeeeseeee#eeeee#e8&eee? 


BSC Line Protocol Handler Time- 


Out Interval 


BSC Features Specific to 3780 ... 
BSC 3780 Conversational Reply 


Feature 


BSC 3780 Two-Buffer Feature ... 
BSC 3780 Transmission/Receipt 
of BSC Control Characters ... 


Using the BSC 2780/3780 
Protocol Handler 


Line 


BSC-Specific ILORB Values e©oeeee8e8 @ 


Specifying Use of BSC 2780 and/or 


3780 to the System 


BSC Input Data 
BSC Control Byte 
ASCII Input for BSC 


BSC Output Data 

BSC Control Byte 
BSC ASCII Output 
BSC EBCDIC Output 


Formats and Characteristics of 


(Receive) 


EBCDIC Input for BSC ....-.eee5. 
Transparent EBCDIC Input for 
BSC bin evalcigs rie tio ea eR SO ees abe Ww, OS OURS 


Formats and Characteristics of 


(SEND) 


BSC Transparent EBCDIC Output . 


Communications SubsyStem ..cccccccees 


Communications Supervisor 


Line Protocol Handlers 


(LPHS) 


Multiline Communications Processor 


(MLCP) 


Multiline Communications Processor 


Driver 
Modem Support 
Auto Call Unit 


Communications Subsystem Operation 


Example 


Communications Subsystem Error and 


Correction Procedures 
Parity Error Check 


Block Error Check eaeeeee#eee#28eeeeeees8 ee 


Longitudinal Redundancy Check 


(LRC) 


Cyclic Redundancy Check (CRC) . 


ae a 
Co 00 CO 


bs Ys 
oso 
1 of 
bh bY 
LO 


7 TTT 
W HHH 


es 
& WW 


I 
iN 


. 
© © 


CBO03 


Appendix A (cont) 


Appendix B 


Appendix C 


Appendix D 


Appendix E 


Appendix F 


Appendix G 


CONTENTS (cont) 


BSC Block Check Character 
(BCC) @eeeeeeeeeee?ee#e?e#e#@eee?eseee2ee@ 
Time-Out Check @eeeee#sLke#eeee?se&eeee8e8e0 @ 


Changing Terminal's File 
CharacteriSt yes: ec s:6e-eceee sews ees 


Resource Control Table (RCT) ......-- 


Sample Application Programs ......... 


COBOL Program ExampleS .eccccccccce 


COBOL TTY or VIP Application 
EXAM PLC: asere's.6-0-wisi ea ee ieele 4 oie wee 
Commands in the COBOL Example . 
File Assignments in COBOL 
EXAM DIC eae Sexe. be: ies we woe wew Sew ete 
Error Messages in COBOL 
—EXAMple wee cccccccccscsccccecs 
Status Codes in COBOL Example . 
Execution of COBOL TTY or VIP 
Program Example weccccsescvce 
COBOL BSC Application Example ... 
FORTRAN Application Example for 
jin Aiea ae ee ee ee ee ee eS ee ee ee ee 
Assembly Language Example for TTY 
or VIP Using Physical I/O ..... 


ASCII and EBCDIC Control Characters 
and Character SECS 6.06.6 Sse ie. %4:% aces 
Control. CHAPTaACtEGrsS. 4% 6666s d 56 Swe 
Special Graphic CharacterS ......-e. 


Device-Specific Control Characters .. 


Dump Routine (DUMCP) for Multiline 
Communications Processor (MLCP) ... 
Linking the Bound Unit Containing 

DUMCP cecccsecccesesccsnceccessece 
Linking DUMCP as a Self-Contained 
BOUNG: UNDE. g-csievs-Sereee ee woe 60-66 
Linking DUMCP With the Applica- 
ELON. PROGRAM: “g'sn0 erw.ob58-4 aoe. seals 
STRTDO Entry Point in Using 
DUM CP a5: 1:6.) selene: w%: ee eho 06-47 e10%6 
STRTD1 Entry Point in Using 
DUMCP® piso: 20 eer. ele Sore ai eee esac eee 
STRTD2 Entry Point in Using 
DUM CODY ie:ia sao osa'en ope Sis edp eb eew oe! wore 


xiii 


Appendix G (cont) 


Figure 
Figure 


Figure 


Figure 


Figure 


Figure 
Figure 


Figure 
Figure 


Figure 
Figure 
Figure 


Figure 
Figure 


Figure 
Figure 
Figure 
Figure 


Figure 


CONTENTS (cont) 


DUMCP Dump FormatS .cecccoccccccceces 
DUMCP Prog YVamming: 66-6 eis-4i6-<6.0 @erece-s% 


ILLUSTRATIONS 


File Information Block (FIB) ..weccceeee 
Format of File Information Block (FIB) 
for Data Management ..ccccccccvvcccce 
Format of File Information Block (FIB) 
for Storage Management ..cccceccccvees 
COBOL SELECT and ASSIGN Examples ...... 
Simplified COBOL Program Logic for 


Multiple Interactive Terminals ...... 


Caimnti FAAnA Derannvam Tanin Fav 972N ROL 
Wei pee eeeuU FeUYse ai BUYse LU BHUY Bor 


Simplified Program Logic for BSC 3780 . 
Simplified Program Logic for Single 
Interactive: Terminal). <:s<.<6004<6 a e-e-es 
Simplified Program Logic for Multiple 
Interactive TerminalS w.ccccccccccece 
Simplified Program Logic for BSC 2780 
in Basic Transmission Mode .ecccevees 
Simplified Program Logic for 2780 BSC 
in Advanced Transmission Mode ......-. 
Simplified Program Logic for BSC 3780 
in Advanced Transmission Mode ...ceoe 
Communications Input/Output Request 
BLOCK. (LORB). +6.6-4<6 esos ob we ow ww ee oe od 
TTY Message FormatS ceccccccccccccsvcee 
Control Byte for TTY Line Protocol 
HANG LEY 6:c:a20. 6:56: 86 6 ww 6.0% © wre, 06 we She Oe 
VIP Control Byte (Send) ...cccccccccvee 
Typical PVE Configuration ..crccrcecces 
VIP Protocol Message Structure for 
PVE? so: tise-e: 6:core 6658 Ge ew. 0) 0 ei 66 Were eases Orel e Sree: 
Example of BSC Communication .....eceee 
BSC Two-Buffer Feature in Record 
TEANSMISS1LON: 2% 66.06: 0 0-0 % Oe alee Sa ew 56% 
BSC Temporary Text Delay (TTD) Sequence 
EXAMDLG: 626.66 ese eo 4s wwe 66 S's 6 Se 60 2S we 
BSC Wait Before Acknowledge (WACK) 


sequence Example Ss Ser ae ne cas Ni res fas it iy Seger ey 


BSC Reverse Interrupt (RVI) Sequence 
EXQMDPL GC: 66:56 WGise S10-0.6 swe Oe we ee eee wees 

Example of Conversational Reply in BSC 
3780 Transmission Sequence ...ececveee 

BSC Input Data Format and Contents .... 


xiv 


CB03 


ILLUSTRATIONS (cont) 


Figure 10-8. Control Byte (Receive) for BSC Line 
Protocol Handler «scssi06.0044009 000 6% 
Figure 10-9. Format and Content of BSC Output ...... 
Figure 10-10. Control Byte (Send) for BSC Line | 
Protocol Handler s66456.6s4%6 86644 6606-8 
Figure A-l. Simplified Flow - Communications 
SUDSYSECI <awueseawecde Tere r eT ee ee or" 
Figure C-l. Format of Communications Resource 


Control Table (RCT) @eeoeoeeee2e7e7eesnoeee#eeseeeteeee e 


Figure D-l. COBOL TTY or VIP Application Example .. 
Figure D-2. COBOL BSC Application Example ......... 
Figure D-3. FORTRAN Application Example for TTY ... 
Figure D-4, Assembly Language Example for TTY or 
VIP Using Physical I/0 ..cccccecccece 
Figure G-l. DUMCP Dump: Example si ssNowws ic vianesew sex 
TABLES 
Table 2-1. Contents of File Information Block 
& CEB), . cevenevane. ee eye eh ere .ave ots o awe e aie Gc eveet ee oe 
% Table 2-2. Contents of FIB for Data Management ... 
Table 2-3. Contents of FIB for Storage 
ManageMent ccccccccecrcvccvvevvecccvsves 
Table 5-1. Arguments for Get File (SGTFIL) Macro 
CALA: * 2e6:Graele oie lee 6 6 -6- Se © 6a Ge Les es 0.58 
Table 5-2. Program View Bit Settings for SOPFIL 
MaCrO* ‘Catal: 26 a:6:0seice.o teers e ee\e oo wea ce Ose were cee 
Table 5-3. Macro Call Procedures for Data Entry 
TOVMINGES ~acedele Ciera @ Swiss 0S oe ee eee 
Table 5-4. Macro Call Procedures for Output Only 
TOCM INAS w-5:6svse-ecd Sree W518 Gave eee @ Weae 
Table 5-5. Macro Call Procedures for Single Inter- 
aCUCIVE TERMINAL. 1e4c-0d.0 Saee-siveye W634 
Table 5-6. Macro Call Procedures for Multiple 
TOYMINaGLS s624cdre eee 8 CE65 we Ooo ees 
Table 5-7. Macro Call Procedures for BSC 2780 in 
BaSic TranSmiSSion Mode ...ccccccccece 
Table 5-8. , Macro Call Procedures for BSC 2780 in 
Advanced TransmisSion Mode ..cccccces 
Table 5-9. Macro Call Procedures for BSC 3780 in 
| | Advanced TransmisSSion Mode .ccccceces 
Table 6-l. Return Status Error Codes for Logical 
, Result of I70: R6EQuUESE: 6 sicécwisie as eee es 
Table 6-2. Contents of Communications Input/Output 
a Request. Block: (IORB) «<c6ss 3.206 s05 004% 
( Table 6-3. software (I ST) Status Codes .......... 
Table 6-4. Communications LPH Function Codes ..... 


XxV 


vata 


TABLES (cont) 


Intervals 


IORB 


IORB 


Intervals 


IORB 


IORB 


UTD Da-~ 
ANT. 


sequence . 


Sequence . 


Handler .. 


IORB 


ITORB 


IORB 


IORB 


IORB 


TTY Line Protocol Handler Time-Out 


@eeeoeeseegce0eee9us#ee#eses#4egeeeee#eee#ees?8tk ee e 


Function Codes in I_CT2 of the IORB ... 
TTY Device-Specific Word I DVS in the 


TTY Software Status Word I ST in the 


VIP Line Protocol Handler Time-Out 


Function Codes in I CT2 of the IORB ... 
VIP Device-Specific Word I_DVS in the 


VIP Software Status Word I_ ST in the 


éeive-Only Printer Editing 


VIP Receive-Only Printer Form Feed 


Errors Reported by VIP Line Protocol 


MLCP Error Condition Reported by VIP 
Line Protocol Handler 
Function Codes in I_CT2 in IORB ....... 
PVE Device-Specific Word I DVS in the. 


PVE Software Status Word I st in the 


eeeoee2eeeec0e8eees8keeeeee#n#eeee#vnoeeeeeests @ 


PVE Time-Out Intervals @eeeee#e##2egee#8e8ete8et 88 @ @ 
Errors Reported by PVE Line Protocol 
Handler 


eeoeee#eeesesseee¢esegee2ee#eoee#eeoe#eetseee#e?#eteeeee ® 


Function Codes in I cT2 Field in the 


BSC Device-Specific Word I_DVS in the 


@eeeoeoeeeeeeesrses?eteeseseee#eee8rt8eeeest ee 


BSC Software Status Word I ST in the 


Possible Argument Values for STTY 


Command and SSTTY Macro Call ..c.cceee 


RCT 


Communications-Specific Items in the 


Terminal Attributes and Status Word 


R STS of the RCT @eeeeseeeses#40#ee®eeoeee7seteeee @ 


ASCII/Hexadecimal Character 
Equivalents 
EBCDIC/Hexadecimal/Binary Character 


Equivalents eeees#esecesceeeee#eeegeeesse#eteee#eeteeeeee ee 


TTY Nonalphanumeric Control 
Characters eeveveeveeveveeneeeeeeeeoee ee eee 8 ee 


xvi 


Table F-2. 
Table F-3. 
Table G-l. 


Table G-2. 


TABLES (cont) 


VIP Nonalphanumeric Control 
CNAVACUCeLS: 643 cco eC aie oe ee aes oes 
BSC Nonalphanumeric Control | 
CRAVACECIS %.erséie-6:s0e a We 026: Seba, ee- eee are 
Register Values and DUMCP Dump 
COMEGN ES. 6.6: oee66-e. Sia -6 6 60-8 00 Ww Bee a Ww 0 
Register $R2 at Dump Execution - DUMCP 
Linked to Application .ecccccccccceese 


XViil 


CB03 


«lhe 


SECTION 1 


COMMUNICATIONS OVERVIEW 


GCOS SOFTWARE OVERVIEW 


The GCOS 6 Operating System includes the Monitor, file sys- 
tem, physical input/output (P I/0), and communications software. 


The Monitor controls loading of user programs, Supports exe- 
cution of user applications tasks, and provides system services 
for users to control execution of separate tasks. Monitor func- 
tions are obtained through commands, through system macro calls, 
and through statements in higher level languages. 


The operating system has two levels of interface with remote 
and local terminals; they may be accessed indirectly through the 
sequential file interface of the file system's file management 
facility, or directly through the system's physical I/0 facility. 


The file system, which is based on a tree-like hierarchical 
directory/pathname structure, provides software to create and 
maintain that structure, to create and manage files, and to pro- 
vide the logical transfer of data between an application and an 
external device. These functions are available through commands, 
and for an assembly language programmer, through the system ser- 
vice macro calls of the file system. 


The physical input/output (or physical I/O) driver software 
(for peripheral devices), and similar line protocol handler soft- 
ware (for communications devices) work at the physical hardware 
level. Physical I/O is used with assembly language programs to 
call device drivers and line protocol handlers directly. 


Communications software, through the file system, uses sys- 
tem service macro calls for communications data operations with 
all languages. For assembly language applications, communica- 
tions software, through physical I/O, provides the data opera- 
tions that are provided by the file system, plus additional con- 
trols over terminal functions at the hardware physical level. 
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The System Concepts manual describes the file system and 
file system structure in detail, and is necessary in understand- 
ing system terms, directory/pathname structures, and system func- 
tions that may be referred to in this manual. 


GCOS 6 File System 


The file system includes an extensive set of logical input/ 
output access methods that handle logical input/output for all 
Supported peripheral devices and terminals. The file system pro- 
vides sequential file processing for communications, treating 
communications devices as sequential files. A file is the basic, 
or lowest level structural unit that can be referred to in the 
file system software. Within the file system, a file can be 
generally defined as a peripheral device, as a terminal device, 
Or aS an aggregate of data. 


Section 2 summarizes the file system macro calls and data 
Structures that are used in communications processing. Sections 
3, 4, and 5 discuss the file system interface in communications 
processing in COBOL, FORTRAN, and assembly language, 
respectively. | 


Physical Input/Output (Physical I/0) 


Physical I/O provides all services that are availble through 
the file system, plus other services that permit user control 
over data structures that affect terminals' hardware and operat- 
ing characteristics. With the physical I/O interface, assembly 
language applications can call line protocol handlers directly, 
rather than through the indirect interface provided by the file 
system. . 


GCOS COMMUNICATIONS SUBSYSTEM OVERVIEW 


GCOS communications software can be considered as a func- 
tional group of components known as the communications subsystem, 
which when specified at system building, defines the communica- 
tions environment of the operating system. | 


The communications subsystem interacts with the Monitor to 
service applications programs, and provides all the communica- 
tions software needed with Honeywell-supported communications 
devices, so that the user need not write his own. Communications 
software is user-driven, responding to connects, reads, or writes 
issued by user programs. Through the request I/O ($RQIO) macro 
calls, the communications subsystem provides a common physical 
I/O interface with user programs. 
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The communications subsystem comprises the communications 
Supervisor, the line protocol handlers (one for each class of 
supported communication device), the multiline communications 
processor (MLCP) driver, and the MLCP itself. 


Appendix A describes the overall functions of the communica- 
tions subsystem in more detail. The line protocol handlers for 
specific devices and protocols are described in Sections 7 
through 10. | 


Communications Supervisor 


The communications supervisor, which resides in the central 
processor's main memory, provides the interface at the physical 
I/O level to communications applications programs. It queues 
user programs" requests for services, activates the appropriate 
line protocol handler, interacts with a user application through 


-system software when a transaction iS complete, and services 


connect/disconnect requests and timeouts for line protocol 
handlers. 


Line Protocol Handler (LPH) 


A communications protocol is a set of conventions for trans- 
mitting data over a communications line. A line protocol handler 
(usually referred to as an LPH) is the memory-resident reentrant 
and interrupt-driven program that transfers data between a commu- 
nications device and the application program or system that uses 
that device. Each LPH Supports a specific class of device, e.g., 
teleprinter-compatible terminal (TTY), or Supports a communica- 
tions protocol, e.g., binary synchronous communications (BSC). 


Other functions of an LPH are: 


o Handling error recovery (by parity or block control 
check) 


o Initializing the LPH and the channel control program of 
the multiline communications processor 


o Processing interrupts, timeouts, and I/O requests 
o Handling affirmative or negative acknowledgments 
Defined at system building, an LPH can be any of the eoaiga inion 
TTY 
Siupares asynchronous terminal devices generically 
classified as teleprinter-compatible (TTY), including 


certain ASR, KSR, and visual information projection 
(VIP) terminals. 
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VIP 
Supports synchronous VIPS and receive-only printers 
(ROPS) 

PVE 
Services the polled VIP emulator (PVE), or keyboard/ 
screen features of the VIP 7700 operating according to 
the polled VIP protocol 

BSC 


Supports a station (device) operating under binary 
synchronous communication (BSC) 2780 or 3780 
compatible protocol. 


Appendix A has a more detailed description of line protocol 
handler functions. 


The user may write his own line protocol handler provided it 
conforms to the same internal interface requirements used by the 
Honeywell-supplied line protocol handlers. 


Multiline Communications Processor (MLCP) and MLCP Driver 


The multiline communications processor includes a channel 
control program (CCP) for each class of Supported device. The 
MLCP driver, which resides in main memory when defined at system 
building, sets up and processes input/output orders from the line 
protocol handlers, and services MLCP interrupts. The Series 60 
(Level 6) MLCP Programmer's Reference Manual describes the multi- 
line communications processor in detail. 


Communications Subsystem Interface With Applications Programs 


FILE SYSTEM INTERFACE 


The file system interface, operating between the application 
program and the terminal, provides, through communications soft- 
ware, system service file management macro calls that: 


Open the file 

Read data from the file (or device) 
Write to the file (or device) 

Test for completion of processing 
Wait for completion of processing 
Close the file 


000000 


COBOL and FORTRAN run-time routines issue these macro calls 
according to the corresponding input/output statements in the 
compiled programs (See Sections 3-and 4). File system services 
are available also to assembly language programs (see Section 5). 
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Section 2 describes these system services macro calls and 


data structures briefly, the System Service Macro Calls manual 
describes all GCOS 6 macro catts ana related data structures in 
detail. | 


PHYSICAL INPUT/OUTPUT INTERFACE 


The physical I/O interface permits direct user control over 
communications processing. The physical I/O interface can be 
used only with assembly language programs, which can call a line 
protocol handler directly rather than indirectly through the eae 
system interface. 


Physical I/O macro calls used in communication between an 
application and line protocol handler are: 


o Request I/O transfer (SRQIO) 
o Input/output request block, generate (S$IORB) 
o Set terminal characteristics (SSTTY) 


Section 6 discusses physical I/0, the macro calls, and data 
structures in more detail. | 


TTY and VIP Line Protocol Handler Device 2 deka 


Asynchronous devices supported by the TTY ita eres 
handler are referred to throughout the manual as teleprinter- 
compatible or TTY devices. 


Synchronous devices Supported by the VIP line protocol 
handler are referred to throughout the manual as VIP devices. 
The VIP deSignation applies also to receive-only printers (ROPs) 
associated with a VIP terminal. : 


BSC and PVE Host-Communications Support 


Binary synchronous communications (BSC) permits communica- 
tion between a Level 6 and another computer system that suppoorts 
the 2780/3780 protocols. 


The polled VIP emulator (PVE) permits a Level 6 computer to 
communicate with another Level 6, Level 66, or any other 
Honeywell host system. 


Sections 9 and 10 have detailed descriptions of the BSC and 
PVE line protocol handlers. 
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SECTION 2 


FILE SYSTEM FUNCTIONS AND MACRO ROUTINES 


This section discusses those macro routines and related data 
Structures that pertain to communications processing and are 
often referred to throughout this manual. The System Service 


Macro Calls manual describes in detail the format, functional 


description, and arguments for each macro routine, and corre- 
sponding data structures. 


The macro routines Summarized and listed in this section 
have the following file system functions, which are organized 
according to the following major functional groups: 


o File/management 
o Data management 
o Storage management 


The file management macro routines provide service functions 
at the file level (i.e., reserving files, opening and closing 
files, testing the status of I/O activity, etc.). Data manage- 
ment macro routines supply service functions at the record level, 
such as read, write, delete, and rewrite. Storage management 
macro routines furnish service functions such as read and write 
at the block (unit of transfer) level. Since terminal files are 
are considered to be simple, unblocked sequential files, storage 
and data management functions are equivalent. 


FILE MANAGEMENT MACRO CALLS 


The file management macro calls let the user manipulate his 
files within the file system hierarchy (described in the System 


Concepts manual). File management macro functions that apply to 


communications processing are: 
o Get a file (reserve a file for processing) (SGTFIL) 
o Open a file (SOPFIL) 


o Close a file (SCLFIL) 
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o Remove a file from processing ($RMFIL) 

o Associate a logical file number with a pathname (SASFIL) 
o Dissociate a logical file number from a pathname (SDSFIL) 
o Get information about a file (S$GIFIL) 


o Test the status of an outstanding I/0 activity (terminal) 
(STIFIL/STOFIL) 


o Wait for the completion of an asynchronous I/0 activity 
(terminal) (SWIFIL/SWOFIL) 


The file reservation function (get-file) can be done out- 
Side program execution by the GET command. 


DATA MANAGEMENT MACRO CALLS 


The data management macro calls allow manipulation of logi- 
cal records within a file. The macro calls that apply to com- 
munications procesSSing are: | 


o Write a record (SWRREC) 
o Read a record (S$RDREC) 


Arguments required by these functions are passed ina file 
information block (FIB), described later in this section. The 
macro calls to generate and change FIBs and to define FIB offsets 


are discussed in the System Service Macro Calls manual. 


Before any data management macro calls can be executed, the 
terminal file must have been reserved and opened with the LFN 
Supplied in the FIB (get file (S$GTFIL) and open file (SOPFIL) 
macro calls). 


STORAGE MANAGEMENT MACRO CALLS 


The storage management macro calls provide a primitive 
interface for transferring blocks directly between the user buf- 
fer and a file. Storage management itself is used by data 
management to perform input/output. 


The complexities of blocking and deblocking logical records, 
and conforming at the same time to the various file organizations 
and formats, recommend against using storage management when 
dealing with I/O at the logical record level. To ensure maximum 
efficiency in terms of space and access, let the system (i.e., 
data management) handle the records. 
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However, for unblocked records or large blocks with simple 
fixed-length records to be blocked by the user, the storage 
management macro calls can be used to perform I/O transfers 
between the user buffer and the file. 


Storage management macro functions are: 


o Read a block (SRDBLK) 
o Write a block (SWRBLK) 
o Wait for the completion of an I/O activity (SWTBLK) 


FILE INFORMATION BLOCK (FIB) 


Some macro routines, particularly for data and storage 
management, use a data Structure called the file information 
block (FIB), which provides the interface between a user program 
and the system for data and storage management. In order for the 
file to be accessed, there must be one FIB for each file. 


The SFIB macro call is used to build a file information 
block, alter its contents, or to provide labels for its entries. 


The FIB must be provided to each of the following macro 
calls: 


SOPFIL: open file 

SCLFIL: close file 

STIFIL: test file for input 
STOFIL: test file for output 
SRDREC: read record | 
SWRREC: write record 

SRDBLK: read block 

SWRBLK: write block 


FIB Format and Contents 


Figure 2-1 shows the format of the FIB; Table 2-1 shows its 
contents. | 


Figure 2-2 shows the format of the FIB for data management 
applications; Table 2-2 shows its contents. 


Figure 2-3 shows the format of the FIB for storage 
management applications; Table 2-3 shows its contents. 
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Figure 2-1. 


F_LFN 
F__PROV 


F__URP/F_.UBP 


F_IRL/F_BFSZ 
F_ORL/F_BKSZ 
F_LIRT/F_BKNO1 
F__HIRT/F__BKNO2 


F_ORT RESERVED | 

cae INPUT KEY POINTER 

F_IKF/F_IKL INPUT KEY FORMAT/INPUT KEY LENGTH 
F_ORA1 (LEFT) OUTPUT RECORD ADDRESS 
F_ORA2 (RIGHT) OUTPUT RECORD ADDRESS 
F_RFEU 
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LOGICAL FILE NUMBER 
PROGRAM VIEW 


0] 1 
USER RECORD/BUFFER POINTER 
| 


Prem rire 


File Information Block (FIB) 


Contents of File Information Block (FIB) 


0 


Logical file number (LFN) 


Access level - set on for storage 
management, off for data management. 


Process rules - bit 1 for SRDREC/ 
SRDBLK, bit 2 for SWRREC/SWRBLK, bit 3 
for SRWREC, bit 4 for SDLREC. 


Key type - bit 5 for primary keys, bit 
8 for relative keys, bit 9 for simple 
keys (bits 6 and 7 must be 00). 


Record class - set on for fixed-length 
records only, off for fixed-— and 
variable-length records... 


Record visibility - set on if deleted 
records are to be visible, off if 
invisible. 


Key storage alignment - set on if stor- 


age area begins at odd-byte boundary, 
off if even-byte boundary. 
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Table 2-1 (cont). Contents of File Information Block (FIB) 


Item ee Contents 


F PROV 
casks (cont) 


Record storage area/buffer alignment - 
F_URP/ 


set on if record storage area (or buf- 

fer) begins on odd-byte boundary, off 
if even-byte boundary. 

F IRL/ 

F _BPSZ 

F ORL/ 

F _BKSZ 


F LIRT/ 
F _BKNO1 
F HIRT/ 
F _BKNO2 


FORT 
F _IKP 


F IKF/ 
F _IKL 


F ORAIL 
F ORA2 


F RFU 


Transcription mode - set on if data 
transferred in binary transcription 
mode, off if ASCII mode. 


SynchronousS/asynchronous indicator - 
set: on if SRDBLK/SWRBLK calls executed 
asynchronously, off if executed 
synchronously. 3 


Start address of user record area data 
management) or start address of buffer 
area (storage management). 

Input record length (data management) 
or transfer size (Storage management). 
Output record length (data ates 
or block size (Storage management) 


must be 0000 for data management; 
the left half of the block number 
(F BKNO1) for storage management. 


Must be FFFF for data management; is 
right half of the block number for 
storage management. 


Must be 0000. 
Start address of user key area. 


Input key format (0 for none specified, 
1 for primary key, 2 for simple key) 


Input key length. 


Output record address (left half). 
Output record address (right half). 


Reserved for future uSe. 
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Program View Entry in the FIB 


The FIB's program view entry (item 1 in the FIB) describes 
to the file system how the file is to be accessed, and what the 
file looks like from the programmer's point of view. The file 
system uses the FIB'S contents to ensure that the file is 
accessed only as intended. | 


The bits in the program view entry are read when the file is 
opened. After the file is opened, the user can change only bits 
ll, 12, and 13. Other bits cannot be changed until the file is 
Closed and then reopened. 


Table 2-1 above shows the contents of the program view 
entry indicated as item 1 and labeled F PROV. The System Service 
Macro Calls manual describes the program view entry in detail, 
with reference to its usage for specific file system services and 
Macro calls. 


FIB Displacement Definitions 


Displacement definition macro calls are used to refer to 
specific locations in the FIB and in the various macro call argu- 
ment structures. These calls define standard displacement tags. 


The STFIB macro call defines tags for the FIB for the fol- 
lowing macro calls: | 


Open file (SOPFIL) 

Close file (SCLFIL) 

Test file (STIFIL, $TOFIL) 
Read record (SRDREC) 

Write record (SWRREC) 
Rewrite record (SRWREC) 
Delete record (SDLREC) 
Write block (SWRBLK) 

Wait block (SWTBLK) 
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F IKF/F_ IKL 


F_ORA 


F RFU2 


Figure 2-2. 


LOGICAL FILE NUMBER 


PROGRAM VIEW 


USER RECORD POINTER 


INPUT RECORD LENGTH 


OUTPUT RECORD LENGTH 


RESERVED 


INPUT RECORD TYPE 


OUTPUT RECORD TYPE 


INPUT KEY POINTER 


INPUT KEY FORMAT INPUT KEY LENGTH 


OUTPUT RECORD ADDRESS 


RESERVED 


Format of File Information Block 
(FIB) for Data Management 
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Table 2-2. Contents of FIB for Data Management 


1 


F PROV 0 Access level - OFF to indcate SOPFIL 
to access via data management 


1-4 Access rules - SOPFIL 
Bit 1: ON if SRDREC will be | 
issued | 
Bit 2: ON if SWRREC will be 
issued | 
Bits 3, 4: does not apply - 
set to OFF 


5-9 bo not apply - set OFF 
10 Record length verification - SRDREC 
ON when expecting fixed | 
length record and OFF for 
variable length record 
11-12 Do not apply - set OFF ae 
13 |User record area alignment - SRDREC 
ON if user record record area SWRREC 
begins on odd-byte boundary, 
off if even-byte boundary. 


14-15 Do not apply - set OFF 


2,3) F_URP 0-31 Start address of user record SRDREC 
area SWRREC | 
F IRL 0-15 Input user record area size in SRDREC 
| bytes 


5 as | Output user record area size | $RDREC 
bytes 


Actual record size in bytes SRDREC 
filled by data management on SWRREC 
each macro call 


ia F ORT a | Do not apply - set to 0 
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Table 2-2 (cont). Contents of FIB for Data Management 


Word Label Bit(s) Contents pepe canes 
Macros 


ll 
12,13 


Do not apply - set to 0. 
Do not apply - set to 0 


SRDREC 
SWRREC 


Output record address 
- line sequence number 

filled by data management 
on each macro call 


Reserved - set to 0 


LOGICAL FILE 


PROGRAM VIEW 


USER BUFFER POINTER 


USER BUFFER SIZE 


USER BLOCK SIZE 


BLOCK NUMBER 


RESERVED 


Figure 2-3. Format of File File Information Block (FIB) 
For Storage Management 
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Table 2-3. Contents of FIB for Storage Management 


Sa a a A a SR aE TE aE 


F PROV Access level - ON (to indicate SOPFIL 
access via storage management) 


1-4 Access Rules: 
Bit 1: ON IF SRDBLK will be SOPFIL 
issued 
Bit 2: ON if SWRBLK will be 
issued 
Bits 3-4: Does not apply - set 
to OFF 


pspale. Do not apply - set to OFF 


13 User buffer area alignment - SRDBLK 
ON if user buffer area begins SWRBLK 
on odd-byte boundary, OFF if 
even—byte boundary 


14- 15 Do not apply - set to one 


F UBP Start address of user barat SRDBLK 
area SWRB LK 


User buffer size in bytes  $RDBLK 
SWRB LK 


Actual transfer size in bytes SRDBLK 
filled by storage management SWRBLK 
on each macro call 


F BKNO Block Number - does not apply 
Line sequence number filled SRDBLK 
by storage management on SWRBLK 
macro call 


== Reserved - set to 0 Lenamoemacseantl 


FILE SYSTEM CONSIDERATIONS IN COMMUNICATIONS 


The file system provides device independent facilities so 
that terminals can be reserved, removed, opened, closed, read and 
written just like standard sequential files. In addition, asyn- 
chronous I/O facilities are provided for efficient processing in 
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a multiterminal environment. Asynchronous I/O refers to the 
capability of the file system to perform I/O between a terminal 
and a system buffer while the application program executes in 
parallel. Facilities are available for the application program 
to test whether or not the I/O is complete and, alternatively, to 
give up control of the central processor until the I/O is com- 
lete. This buffering capability is a device attribute and can 

be set at system build time or dynamically via the STTY command. 
The: system buffer is actually acquired when the terminal is 
opened and returned when it is closed. 


From the application program point of view: 


o An application program can be written to be device 
independent. The terminals, whether or not buffered, 
whenever a logical read or write is issued, control 
returns only to the application program when data has 
been moved to or from the application area. Buffering 
improves performance by providing the same level of 
asynchronous I/O as for unit record devices like the 
card reader or line printer -that is, while the applica- 
tion is processing one message the file system may be 
reading the next. This kind of application is efficient 
in a Single terminal environment. 


o A more complex level of asynchronous I/O iS necessary 
when the application program must interact with multiple 
terminals, establish its own polling priorities and run 
efficiently with high response time. One example is 
the traditional online/batch environment where, when 
terminal input is available, the online task has highest 
priority with. respect to CP time, memory, etc., with 
batch processing operating efficiently while online 
processing is dormant. Facilities are available to 
schedule I/O without waiting for its completion, to 
continue task execution in parallel with the I/0 
transfer, to test to see if the I/O is complete, and 
to wait until I/O is complete. 


o For interactive terminals an open causes an asynchronous 
physical connect to be performed while the application 
continues executuion. The application can then test to 
determine if the connect is complete and input is avail- 
ble, or if the device is ready for output. 
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o Before reading, the application task can test the file 
Status to see if a read can be done without stalling 
task execution. File status remains busy until the 
system buffer is full (i.e., the anticipatory read is 
complete). When the file status is not busy the appli- 
cation can issue a read with the asSurance of receiving 
data immediately. The anticipatory read allows an appli- 
cation to control input from more than one terminal, each 
of which represents a data entry terminal. By testing 
the status of the system buffer before a read 
(FORTRAN assembly) or by checking for the 9I status after 
a COBOL READ, the application will not be stalled and it 
can continue to poll other terminals. The uSer can 
establish the order of the tests and thus the polling 
priority. | 


o The application can also wait for input from a list of 
terminals. CP time is then made available to lower 
Driority tasks until input is available from one or 


more terminals in the list. 


o A buffered write operation to a terminal works on behalf - 


of the application program in the same logical manner as 
the read, that is, the program is allowed to execute in 
parallel with the physical transfer to the device. Each 
write call is completed by moving data from the ,applica- 
tion area to the file system buffer (with detabbing if 
required), initiating the output transfer and returning 
control to the application program. If the program 
performs a second write while the system buffer is still 
in use for the previous transfer, the application is 
stalled until the buffer is available and new data moved 
into it again. The application can avoid the stalling 
the execution by testing the status of the system buffer 
before issuing a write (FORTRAN,assembly) or by testing 
for the 9I status return after a WRITE in COBOL. 


o The application program can also isSue a wait for output 
to a list of terminals. CP time is then made available 
to lower priority tasks until output is complete to one 
or more terminals in the list. 


DEFINING FILE/TERMINAL CHARACTERISTICS 


There are these considerations in defining terminal file 
characteristics for the file system. The first deals with a 
file's operational characteristics (with respect to the device) 
when the system is first build. The DEVICE directive permits 
the user to specify among others the default record size of the 
file and the use of an intermediate buffer (this option is 
specified by the buffered/unbuffered argument). Buffered device 
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operation is advantageous in synchronous operations against a 
file, and 1S mandatory in asynchronous operations against a 
File. | 


The second consideration involves the secondary specializa- 
tion of a file's device's operational characteristics. This 
specialization can be done at system build by using the STTY 
directive, from the user's terminal via an STTY command, and 
during program execution with the SSTTY macro call. In each case 
the SSTTY macro call or STTY command permits the following: 


o Modification of default record size. 


o Specification of the device-specific word which 
determines the operational characteristics of the 
device (e.g., whether a control byte is used or a 
disconnect will force a queue abort). 


o Specification of the file indicator word which 
determines the operational characteristics of the file 
system (e.g., if the file system is to support input 
and/or output operations, and whether these operations 
are synchronous/asynchronous). 


The final consideration deals with specifying selected file 
characteristics at open time. Of particular interest is the 
program view word of the file information block (FIB), which 
defines whether the file system is to support input and/or output 
operations against a file. 
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SECTION 3 


COMMUNICATIONS VIA COBOL 


The file system interface (see Sections 1 and 2) provides 
the logical transfer between the COBOL program and an external 
device (terminal or another computer). The COBOL run-time rou- 
tines issue file system macro calls according the the correspond- 
ing input/output statements in the compiled programs. 


INTERACTIVE DEVICES AND FILES 


The operating system defines communications devices and 
local TTY terminals in COBOL communications processing as 
"interactive." | 


Interactive devices can be considered as logical reposito- 
ries of Sequential files in COBOL. Data iS read or written with 
the same COBOL read/write interface as for a file on a noninter- 
active device. 


FILE SYSTEM CONSIDERATIONS 


Aside from the use of various COBOL I/O statements the uSer 
Should be aware of other considerations in using the file system 
within a communications environment. These considerations are 
detailed in Section 2. 


SOURCE PROGRAM ENTRIES IN COMMUNICATIONS 


This subsection refers to certain COBOL source program 
entries in the context of COBOL communications. The appropriate 
COBOL Reference manual describes COBOL source program language in 
detail. 


Specifying Files in the Source Program 
The user must describe every file with a separate SELECT 
statement in the FILE-CONTROL paragraph of the Environment 


Division. File organization and access mode must be stated as 
sequential. 
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Each file must have a unique name and, and in the 
ASSIGN clause, be identified by. a 2-character COBOL internal file 
name (IFN) consisting of a combination of the letters A through I 
and the digits 0 through 9; one letter must be included. The 
logical file number (LFN) is specified in the ASSOC or GET com- 
mands.(before execution) to connect the COBOL internal file name 
to the external file. This LFN is the same as the COBOL internal 
file name with letters A through I replaced by the digits 0 
through 9. For example, a COBOL IFN of OC would correspond to an 
LFN of 03 and an IFN of OD to an LFN of 04, as in the commands. 


ASSOC 03 >SPD>OVIPIL 
GET 04 >SSPD>TTY1 


Use of ASSOC or GET Commands 


In addition to connecting the internal file name to the 
external file, the GET command reserves the interactive file for 
processing until it is removed via the REMOVE command. GET 
allows the user to guarantee exclusive use of the file prior to 
program execution and maintain use of the file until the corre- 
sponding REMOVe command. 


ASSOC, on the other hand, merely connects the internal file 
name to the external file, without reserving it for use. Each | 
COBOL OPEN statement will cause the file to be reserved exclu- oe 
sively while each COBOL CLOSE statement will remove this 
reservation. 


In a multi-user environment the use of ASSOC command may 
cause an OPEN to fail because some other user has reserved the 
file exclusively while the GET command guarantees that OPEN will 
not fail as a result of some other user's reservation request. 


ASSIGNING A FILE TO A DEVICE/TERMINAL 


A device-type name of MSD used in the ASSIGN clause of the 
SELECT statement is the way that the user informs COBOL that the 
internal file is assigned to a terminal/device file. 


For data entry ne anaes (TTY or VIP) the file should be 
opened in INPUT mode. 


For output-only terminals such as the Receive Only Printer 
(ROP) the file should be opened in OUTPUT mode. Bidirectional 
devices, such as the BSC 2780 can be opened in INPUT mode or 
OUTPUT mode but not for both INPUT and OUTPUT at the same time. 


For interactive applications (TTY, VIP or BSC3780), the file 


can be opened in I-O mode allowing both input and output _— 
operations. , Ae 
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SELECT and ASSIGN Examples 


Figure 3-1 shows an example of a FILE-CONTROL paragraph with 
SELECT and ASSIGN statements for the input file COMIN and the 
output file COMOUT. The internal file name for COMIN is OC and 
for COMOUT is OD. Before the program is executed, the user must 
associate these files with the appropriate device(s) with either 
an ASSOC or GET command. In this example, the commands could be: 


GET 03 >SPD>TTYL 
GET 04 >SPD>TTY1 


Although these are different files, they can be associated with 
the same interactive. device, i.e., TTY1, by matching the logical 
file numbers (03 and 04 for the device pathname >SPD>TTY1) with 
the internal file name OC and OC, respectively. 


FILE-CONTROL 
SELECT COMIN 


ASSIGN TO OD-MSD 

ORGANIZATION IS SEQUENTIAL WITH VLR 
ACCESS MODE IS SEQUENTIAL 

FILE STATUS IS IN-STAT. 


SELECT COMOUT 


ASSTGN TO OD-PRINTER 

ORGANIZATION IS SEQUENTIAL WITH VLR 
ACCESS MODE IS SEQUENTIAL 

FILE STATUS IS QUT-STAT. 


Figure 3-1. COBOL SELECT and ASSIGN Examples 


Carriage Control 


Some devices can be configured such that print carriage con- 
trol is visible on output to the application program. If the 
device-type name is MSD, then the application program controls 
the carriage directly by inserting a program—-accessible control 
byte as the first character in each output record. This byte is 
the first character in each level-0Ol record description entry for 
the output file. It is counted as part of the record area and is 
directly accessible through statements in the COBOL application 
program. 
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Printer Emulation 


The user can pretend the device iS a printer and more auto- 
matically control the carriage. If the device-type name is 
PRINTER in the ASSIGN clause then COBOL will automatically gener- 
ate the carriage control byte as a result of an ADVANCING phase 
in the WRITE statement. This one byte print control character is 
inserted before each data record being written to the file. It 
is not counted as part of the record area and is not directly 
accessible tot he application program. 


Specifying Asynchronous or Synchronous Read and Write Execution 


If the device is configured with the asynchronous I/0 attri- 
bute then READ and WRITE statements may be executed synchronously 
or asynchronously, as indicated by the programmer through calls 
to the COBOL run-time routines ZCASYN (aSynchronous execution) or 
ZCSYNC. (Synchronous execution). If neither call is specified, 
reads and writes are executed asynchronously. 


A separate call to ZCSYNC or to ZCASYN is not necessary for 
each read or write, but when first issued, remains effective 
until changed by another call. However, if the same run unit is 
to execute several COBOL programs, each program must separately 
define its own synchronous or asynchronous condition. 


SYNCHRONOUS READ AND WRITE OPERATION (CALL "ZCSYNC") 


In synchronous operation, the COBOL routine issues a read or 
write order without any file status checks. This causes the 
application program to be put in the wait state until the read or 
write operation is complete, thus allowing other tasks to be 
executed. 


The Source language for synchronous read and write execution 
iS: 


CALL "ZCSYNC" 


Synchronous operation is not very useful in a multiterminal en- 
vironment since each read or write to a terminal must be satis- 
fied before the next terminal can be processed. 


ASYNCHRONOUS READ AND WRITE OPERATION (CALL "ZCASN") 


In asynchronous operation COBOL READ/WRITE run-time routines 
issue a test-file call prior to issuing a read or write order. 
For READ orders, a 9I return status is returned to the applica- 
tion if no data is available to be read. Likewise, for a WRITE _ 
order, a 9I status is returned to the application if the device —_ 
is busy with the previous output. This permits the COBOL program a 
to Support terminal I/O without giving up control of the central 
processor until the I/O is complete. 
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WAIT for Completion -- Asynchronous Input and Output 


In a multi-terminal system the user can control asynchronous 
read and write operations by calling the COBOL run-time routines 
ZCWIN and ZCWOUT. 


A call to ZCWIN results ina wait file (SWIFIL) macro call 
which waits until input is available from one or more of the 
specified terminals. 


A call to ZCWOUT results in a wait-file (SWOFIL) macro call 
which waits until output is complete to one or more of the 
specified terminals. 


The System Service Macro Calls manual describes the wait 
file macro calls, their format and arguments, in detail. Note 
that the macro call arguments are Similar to the values for the 
data-name description for the CALL statements (see below). 


The source language to call ZCWIN or ZCOUT is: 


CALL J"ZCWIN" (USING data-name 
"ZCWOUT" 


Data-name is defined as follows: 


Ol data-name 
O02 out-LFN USAGE COMP-1. 
O02 list-length USAGE COMP-1. 
O2 LFN-entry-1l USAGE COMP-1. 


O02 LFN-entry-n USAGE COMP-1. 


The values for out-LFN, list-length, LFN-entry-1l and LFN-entry-n 
are identical to those for the wait file (SWIFIL and (SWOFIL) 
macro calls, and are passed by the ZCWIN or ZCWOUT routine to the 
file system. | 


When CALL "ZCWIN" is specified, the list of LFNs may refer 
only to hose devices for which READ statements have been issued. 
When call "ZCWOUT" is specified, the list of LFNs can refer only 
to those devices for which WRITE statements have been issued. 


When an input/output operaton is completed on any device in 
the list of LFNs, the application program resumes execution fol- 
lowing the CALL statement. The LFN for the device for which 
input/output is complete is stored in the out-LEN data item. 
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Figure 3-2 provides simplified program logic for processing 
multiple terminals. The call to "ZCWIN" stalls program execution 


until input is available from at least one of the terminals. 


OPEN I—O (FILE 1) 


OPEN I—O (FILE 2) 


OPEN !—O (FILE 3) 


CALL "“ZCWIN” (FOR FILES 1, 2, 3) 


NOT BUSY — FILE N 


READ (FILE N) 


MORE 
INPUT 
EXPECTED 


CLOSE (FILE 3) 


CLOSE (FILE 2) 


CLOSE (FILE 1) 


Figure 3-2. Simplified COBOL Program Logic for 


Multiple Interactive Terminals 
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The following is an example of a COBOL program which pro- 
cesses two terminals which have been configured to allow asyn- 
chronous input and synchronous output operations. The call to 
ZCWIN gives up control of the central processor until input is 
available from one of the terminals. 


FILE-CONTROL. 
SELECT COM1 


ASSIGN TO OC-MSD 

ORGANIZATION IS SEQUENTIAL WITH VLR 
ACCESS MODE IS SEQUENTIAL 

FILE STATUS IS C1l-STAT. 


SELECT COM2 


ASSIGN TO OD-MSD | 
ORGANIZATION IS SEQUENTIAL WITH VLR 
ACCESS MODE IS SEQUENTIAL 

FILE STATUS IS C2-STAT. 


PROCEDURE DIVISION. 


OPEN I-O COMI. 
OPEN I-O COM2. 


RD1. 


CALL "ZCWIN" USING FLN-LIST. 
READ COMI. 

IF C1-STATE "9I" GO TO RD2. 
IF C1-STATE "00" GO TO WRI. 
GO TO ERROR. 


RD2. 
READ COM2. | 
IF C2-STAT "00" GO TO WR2. 
GO TO ERROR. 
WR1. 
WRITE COMLI. 
IF Cl1-STAT "00" GO TO RDI. 
GO TO ERROR. 
-WR2. 
WRITE COM2. 


IF C2-STAT "00" GO TO RDI. 
GO TO ERROR. 
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Before program execution, specify these commands to connect Ne 
the LFNs to the specific terminal files. 


GET 3 >SPD>TTY1 (for IFN OC-MSD) 
GET 4 >SPD>TTU2 (for IFN OD-HSD) 


Binary Synchronous Communication (BSC) With COBOL 


Binary Synchronous Communication (BSC), operating in 2780 or 
3780 mode, permits a COBOL program to transmit data over communi- 
cations lines from one Level 6 system to another Level 6, to a 
Level 66 system, or to a non-Honeywell host system. 


BSC DATA TRANSMISSION CONVENTIONS 
BSC Data Codes 


Data can be in alphanumeric ADCII, alphanumeric EBCDIC, or 
binary format. In communication between Level 6 and remote host, 
each system must use the Same code set (either ASCII or EBCDIC). 
When EBCDIC is used, the application programs must know whether 
transmission is nontransparent or transparent (i.e., BSC control 
characters are interpreted as data). 


BSC Data Transmission Modes | a i 
There are two BSC transmission modes: basic and advanced. 


In basic transmission mode there 1S no control byte. The 
absence of a control byte limits the functionality of the proto- 
col (e.g., an application cannot send or receive two message 
blocks or cannot initiate a reverse interrupt (RVI) sequence). 


In advanced transmission mode there is a control byte which 
is the first byte in the program's input or output buffer. The 
control byte is used to control the transmission of data and is 
used to convey information concerning the receipt of data. With 
the control byte, the application has complete control over the 
transmisSion and reception of data to a remote host. 


BSC 2780 and BSC 3780 


BSC 2780 is a subset of BSC 3780. Technical differences 
between the two protocols can be Summarized as a set of exten- 
Sions to the 2780 protocol which are as follows: 


o The ability to receive a conversational reply without a 
preliminary bid sequence. 


o The ability to receive and transmit selected BSC control — 
characters. Ls. 
| 
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From a user's point of view the differences between the two 


protocols can be summarized below: 


o BSC 2780 


Specified at system building time by the BSC device 
directive. 


Operates in basic or advanced mode. 


The file system supports bidirectional uSage of 

BSC 2780 communication line. A CLOSE/OPEN sequence 
must be initiated prior to the reversal of the com- 
munication line. 


o BSC 3780 


Specified a system building time by the XBSC 
directive. 


Operates only in advanced mode. 


The file system supports interactive usage of the 

BSC 3780 communication line. To terminate a transmis-— 
Sion the application must initiate an EOT sequence by 
setting the appropriate bit within the control byte. 
An ETX message transmisSion sequence can also be 
terminated if the other application sends a conversa- 
tional reply. The receipt of conversational reply is 
indicated by a bit setting within the transmit control 
byte. The receipt of a conversational reply forces 
the application to issue a read order to receive the 
conversational response. The termination of a read 
sequence is indicated by the AT END condition. 


Macro Call Procedures for BSC 2780 in BaSic Transmission Mode 


The following conditions apply in the use of binary synchro- 
nous communications in basic data transmission mode: 


o An application cannot send an RVI (reverse interrupt) 
control character through the file system. 


o BSC devices in basic transmission mode cannot initiate 
double (ITB) message transmission (see Section 10). 


o An application can send only the ETB (end of transmission 
block) BSC control character, not the ETX (end of text). 
BSC control character. 


( o An application can send data in either a or 
= nontransparent mode. 
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o An application can send EOT (end of transmission) control 


characters by a CLOSE call. 


o BSC operation assumes that the detab option is set off. 


Figure 3-3 illustrates the necessary logic to Support a 


BSC 2780 application in basic transmission mode. 


OPEN INPUT 


YES YES 


NO NO 
AT 
END ERROR e 


CLOSE 


CLOSE 
EXIT 


<=> . 
-YES 


EXIT 


OPEN OUTPUT 


CALL “ZCWOUT 


Figure 3-3. Simplified Program Logic for 2780 BSC 


3-10 


CBO03 


ue - Z 


AEE 


Macro Call Procedures for BSC 2780 in Advanced Data 
Transmission Mode 


In the BSC advanced data transmission mode, the first byte 
of the application program's input or output buffer is a control 
byte that controls or Supplies information about read/write oper- 
ations. This byte can indicate, for example, whether data is to 
be transferred in transparent or nontransparent mode, or whether 
an ETB (end of tranSmission block) or ETX (end of text) control 
character is to be sent or received. Section 8 describes the 
control byte formats. | 


The following conditions apply in using the file system in 
2780 binary synchronous communications in advanced data transmis- 
sion mode: 


It is not necessary to send EOT control characters through 
the control byte since the user must close the file in 
output mode before attempting to read. Closing the file 
forces BSC if not in idle mode, to send an EOT control 
character. 


Macro Call Procedures for BSC 3780 in Advanced Data 


Transmission Mode 


The first byte of the application program's input or output 
buffer is a control byte. The control byte controls or supplies 
information about read/write operations. 


The following conventions apply in using 3780 binary syn- 
chronous communication in advanced data transmission mode: 


o The receipt of an optional conversational reply is indi- 
cated by a bit setting in the transmit control byte. 
(This can occur if the application has transmitted the 
last (ETX) block of a message). The application must 
issue a read in order to receive the conversational 
response. 


o The termination of a transmit Sequence is Signaled (via 
control byte) by the transmission of an EOT control char- 
acter following the last block of a message. Once this 
has been done a read macro call will be needed to receive 
transmissions from the remote system. (It is not neces- 
sary to close and reopen the file to turn the line 
around). 


o The termination of a receive sequence is indicated by the 
AT END condition. A transmission sequence can be reini- 
tiated by issuing another write macro call. (It is not 
necessary to close and reopen the file to turn the line 
around). 7 
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o A line turnaround (receipt of an EOT) is indicated at the bad 
AT END condition. At this point the application can use 
the line for data transmission by issuing another write 
request. It is also possible to receive an EOT control 
character which indicates the abortion of the current 
transmission sequence by the remote host. Such an occur- 
rence is indicated by an AT END condition. If this 
occurs the application must close the line. 


Figure 3-4 illustrates the necessary logic to Support a 
BSC 3780 application. 


Figure 3-4. Simplified Program Logic for BSC 3780 a 
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WRITE 
LAST 
(ETX) 
MESSAGE 


WRITE YES NO WRITE 


(WITH ETX) (WITH ETB) 


CALL “ZCWOUT”’ CALL “ZCWOUT” 


YES YES : 
ERROR CLOSE EXIT ERROR CLOSE 
NO 
NO EXIT 


CONVERSATIONA 
REPLY 
RECEIVED 


YES Ce 


Abe 2. 


NO 


YES 


WRITE 
(WITH EOT) 


NO 


YES 


EXIT 


ae Figure 3-4 (cont). Simplified Program Logic for BSC 3780 
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SECTION 4 


COMMUNICATION VIA FORTRAN 


The file system interface (see Sections 1 and 2) provides 
the logical transfer between the FORTRAN program and an external 
device (terminal or another computer) in FORTRAN communications. 
The FORTRAN run-time routines issue file system macro calls 


according to the corresponding input/output statements in the 


compiled programs. 
INTERACTIVE DEVICES AND FILES 


The operationg system defines communications devices and 
local TTY terminals in FORTRAN communications procesSing as 
"interactive." Interactive devices can be considered as logical 
repoSitories of sequential files in FORTRAN. Data is read or 
written with the Same FORTRAN read/write interface as for a file 
on a noninteractive device. 


FORTRAN PROGRAM EXECUTION WITH COMMUNICATIONS 


Assigning Interactive Devices at Execution 


Before the compiled FORTRAN progran can be executed, the 
user must specify the actual interactive device for the specified 
file, using the system command ASSOC (associate path). The 
logical file number (LFN) specified in the command must be the 
Same as the unit specifier (u) that was included in the control 
information list (clist) in the FORTRAN input/output statement 
READ, WRITE, or PRINT for that file. See the FORTRAN Reference 
manual for descriptions of FORTRAN statements and the unit 
Specifier. See the Commands manual for descriptions of the ASSOC. 
and other system commands. 


Changing Terminal's File Characteristics 


The user can change the file characteristics of a terminal 


e.g., line length (or record size), detabbing, device type 
(input, output, etc.,) with the system command STTY (set terminal 
characteristics), or with the SSTTY macro call. This permits the 
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user to modify the characteristics established at system build- 
ing, and is issued before program execution. 


Appendix B shows possible values for the device-Specific 
word and file-indicator word arguments of the STTY command and 
SSTTY macro call. 


FORTAN FILE STATUS CHECK (ZFSTIN AND ZFSTOT) 


Before a FORTRAN file can be used in communications, the 
FORTRAN statement OPEN must be specified before any other input/ 
output statement. 


The FORTRAN Subroutines ZFSTIN (for input files) and ZFSTOT 
(for output files) enable the application program to check the 
status of the input or output communications device (file) before 
issuing a READ or WRITE Statement. 


When the program issues an I/O request statement (a. READ Or 
WRITE), it stalls until that request is completed. 


The FORTRAN Subroutines ZFSTIN and ZFSTOT, when called 
before an I/O request is issued, check the availability of the. 
communications device (file), and can prevent the problem of pro- 
gram inactivation or program execution due to file or device 
unavailability. | | 


The subroutine ZFSTIN checks the status of the input file, 
ZFSTOT checks the output file. Their use monitors the status of 
the files without loss of program control and prevents the impos- 
ition of file system waits. | 


A CALL statement to either subroutine should be issued 
before the application issues any I/O requests to ascertain (1) 
whether the file (device) is available, and (2) any device error 
status. } 


The subroutine ZFSTIN or ZFSTOT, when called, issues a 
request to the file system, which in turn (without waiting for 
any pending I/O request to be completed) returns status informa- 
tion about the file's availability. When the file is not busy, 
the file system will return status information about the previous 
I/O request. 


CALL Statement for ZFSTIN or ZFSTOT 


The CALL statement for subroutine ZFSTIN or ‘ZFSTOT is 
specified as: 


CALL |ZFSTIN( (lfn,arg) 
| ZESTOT 
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lfn 
The logical file number, in an ASSOC systems command, 
that identifies the unit specifier (u) for the file to 
be checked. 

arg 


The symbolic integer variable into which the file sys- 
tem will return one of the following statis values: 


000,, 
File is available (READ or WRITE can be issued). 
The last request, if a READ or WRITE, was suc- 
cessful. 

512 76 
Request rejected; undefined LFN was used, or the 
file system is not available. 

51649 
File is busy (READ or WRITE in progress). If 
ZFSTIN, then a READ iS in progress and not yet 
complete. If ZFSTOT, the previous WRITE is not 
yet complete. 

51949 


File is not open; last request was not success- 
ful. Issuance of another READ or WRITE will 
result in an error return. 


A call to ZFSTIN or ZFSTOT made to a noncommunications file 
always results in a 000 (not busy) status return. Such a call 
allows a user to debug the application program by first using 
noncommunicsatons files, then write the program so that it can 
use either communications or noncommunications files. 


The FORTRAN Subroutine ZFSTIN, when called before isSuing a 
READ request, checks for the availability of input. It prevents 
the loss of program control until data is available ina file 
system buffer. When ZFSTIN indicates that the file is not busy 
then a READ can be issued to move the data just read from the 
file system to the application program area. 


The FORTRAN subroutine ZFSTOT, when called before issuing a 


WRITE request, checks to see if previous output is complete and 
the terminal is free to accept more data. When ZFSTOT indicates 
that the file is not busy then a WRITE can be issued to move data 
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from the application program area to a file system puree and 
schedule it to be written to the terminal. 


ZFSTIN and ZFSTOT Programming Examples 


The following are examples of (1) coding that causes the 
program to stall when input from a terminal is not completed 
before a second READ is issued, 


and (2) a call to subroutine 


ZFSTIN to check the file status before the second READ is issued. 


Note that in each case the first FORTRAN statement is OPEN. 


Example 1: 


100 


OPEN (UNIT=8) 
READ (8,100) IN 
READ(8,199)IN 
FORMAT (12) 


Fxamnle 2: 


50 


100 
200 
900 
910 


OPEN (UNIT=8 ) 

READ (8, 200) IN 

CALL ZFSTIN(8,ISTAT) 
IF(ISTAT .EQ. 0) GO TO 100 
IF(ISTAT .EQ. 512) GO TO 900 
IF(ISTAT .EQ. 519) GO TO 900 
GO TO 50 . is 
READ (8, 200) IN 

FORMAT (15) 

WRITE (4,910) 

FORMAT (ERROR FOUND) 


Appendix D contains an example of a FORTRAN communications 


program. 
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ASSEMBLY LANGUAGE COMMUNICATIONS USING THE FILE SYSTEM 


This section discusses the use of file system macro calls in 
writing communications programs. 


FILE SYSTEM CONSIDERATIONS 


Aside from the use of macro calls, the user should be aware 
of other considerations in using the file system within a commun- 
ications environment. These considerations are detailed in 
Section 2. 


FILE-PROCESSING MACRO CALLS IN ASSEMBLY LANGUAGE APPLICATIONS 


The following describe the use of the get file (SGTFIL), 
open file (SOPFIL), test file (STIFIL and STOFIL), and wait file 
(SWIFIL and SWOFIL) macro calls in assembly language communica- 
tions processing with the file system. 


Get File (SGTFIL) Macro Call Guidelines 


The get file function reserves a file for processing _ and 
connects a file to a logical file number (LFN). The LFN is used 
in other file system calls (SOPFIL, SRDREC, SWRREC, etc.) to 
reference the file in question. Normally the get File function 
1S involved via a GET command outside of program execution. 


The arguments for the get file (SGTFIL) macro call in an 


assembly language communications program must have the values 
shown in Table 5-1. 
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Table 5-1. Arguments for Get File (SGTFIL) Macro Call 


Pathname pointer 


Must point to a pathname of a communica- 
tions device (e.g., >SPD>TTYO1) 


Concurrency control According to how the application uses the 


device (normally zero for excluSive use) 


Remaining arguments Zero 


Open File ($OPFIL) Macro Call Guidelines 


The open file function allocates buffer space (if required) 
and physically connects the device or terminal. 


The open file macro call SOPFIL, when used in communica- 
tions, muSt include the location ot the tile intormation block 
(FIB) which in turn must contain a valid program view item. 


Table 5-2 indicates bit settings in the program view item 
for the SOPFIL macro call, such settings are dependent on the 
actions taken by the communications application program. 


Test File (STIFIL, STOFIL) Macro Call Guidelines 


Before the application issues a SRDREC or SRDBLK macro call, 
it can issue the test input file (S$TIFIL) macro call to check 
whether input is available. Note that when the operator terminal 
is checked, the STIFIL macro call always returns a not busy 
status. ? 


Before the application issues a SWRREC or SWRBLK macro call, 
it can issue the test output file (S$TOFIL) macro call to check 
whether the preceding output operation was completed. 


Wait File (SWIFIL, SWOFIL) Macro Call Guidelines 


The use of the wait file macro call will permit an applica- 
tion to wait for the completion of an outstanding read or write 
order. The wait file macro call can be used against a set of 
multiple terminals or devices. Test and wait file macro calls 
differ in terms of when control is returned to the calling rou- 
tine. A test file call will return immediately with a busy or 
not busy status. An application can block the execution of 
lower level tasks with repeated test file calls to a busy file. 
Such problems can be avoided by issuing a wait macro call in 
lieu of successive test macro calls. 


SWIFIL is used to wait for input from any device/terminal; 
SWOFIL to wait for completion of output to any device/terminal. 
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Table 5-2. Program View Bit Settings for SOPFIL Macro Call 


Bit set 
Actions by Assembly Language Application Program| Bit(s) 
| | To 


Will use read record (SRDREC) and write record 
(SWRREC) macro calls 

Will use read block (S$RDBLK) and write block 
(SWRBLK) macro calls 


1 Will read data from the device (see note 1) 


Will not read data from the device 
Will write data to the device (see note 1) 
Will not write data to the device 


1 
1 


0 


12 
: 
; 


Notes: 1. Bit value must be consistent with device type being 
used. 


2. When application uses SRDBLK or SWRBLK macro calls, 
| execution of the calls indicates asynchronous. 


Device Dependent Macro Call Procedures 


The following subsections describe the procedures for 
1ssuing device dependent file system macro calls. 


Device Modes and Device Types 


There are four basic processing modes for communications 
devices: 


Input only (TTY or VIP data entry applications); 

Output only (receive only printer application (ROP); 
Bidirectional - either the device is opened for input or 
output, but not both applications (BSC 3780); 
Interactive (TTY, VIP or BSC 3780 applications). 
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Macro Call Procedures for Data Entr 


Terminals 


Table 5-3 shows the procedure for using file system macro 
calls in communications application involving data-entry 


‘terminals. 


Table 5=3:, 


Issue P'tesue SGIPIL macro call (cece macro call (see 
Table 5-1) 


Issue &OPFIL macro call (see 
Table 5-2) with 1 set to l, 
bit 2 set to OQ. 


3 Issue SWIFIL macro call to 
wait unil connect is complete 
and input is available. 
(With multiple devices, 
SWIFIL macro call can be 
issued with a list of LFNs, 
effectively giving up con- 
trol until input is available 
from one or more devices in 
the list.) 


the 


Otherwise, if application is 
to do other processing (not 
giving up control), issue 
STIFIL macro call. 


If not busy status is re- 
turned, issue SRDREC or 
SRDBLK macro call. 


If an error status is re- 
turned, exit from the 
procedure. 


i 


Macro Call Procedures for Data Entry Terminals 


Action Pianeta Oi 2 aceon eiadaica aa Application Program iil eee Actions 


Ete 2 procera view | 2 program view 


Issues asynchronous 
connect, returns a 

normal status to the 
program. . 


Will return when a. 
read has been satis- 
fied. 


If connect is not 
complete return a 
busy status. If 
connect is complete, 
issue an asynchro- 
nous read and return 
a busy status until 
read is complete. 


With read operation 
complete, move data 
from system buffer 
to application's 
buffer, issues 
another asynchronous 
and returns a 


read, 
normal status to the 
program. 
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Table 5-3 (cont). Macro Call Procedures for Data Entry Terminals 


Procedure : 

~ Step Action by Application Program System Actions 
When read is successful, 

return to step 3 to request 

more data from the device. 


When application process- 
ing completed, issue SCLFIL 
macro call. 


| Issues a disconnect. 


Macro Call Procedures for Output Only Terminals 


Table 5-4 shows the procedure for using macro calls in com- 
Munications applications involving output only terminals. 


Table 5-4. Macro Call Procedures for Output Only Terminals 


Procedure 
Step Action by Application ee ee System Actions 


Issue SGTFIL macro aoe SCL Rec al ee (see 
Table 5-1). 


Issue SOPFIL macro call (see Issues a asynchronous 
Table 5-2) with bit 1 set to connect, returns a nor- 
0, bit 2 set to l. mal status to the 
program. 


will return when output 
can be transmitted 


Issue SWOFIL macro call to 
wait until connect is com— 
plete and ourpoe can be 
transmitted. (With multiple 
devices, the SWOFIL macro 

call can be issued with a list 
of LFNs, effectively giving up 
control until output can be 
sent to one or more of the 
devices in the list. 


If connect is not com- 
plete return a busy 
Status. If connect is 
complete return a not 
busy status if output 
can be transmitted. 


Otherwise, if the application 
is to do other processing (not 
give up control), issue a 
STOFIL macro call. 
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Table 5-4 (cont). Macro Call Procedures For Output Only Terminals 


Procedure | : 
step | Action by Application Program System Actions 


2 


Moves data from appli- 
cation buffer to sys- 
tem buffer. Issues 
asynchronous write and 
returns a normal sta- 
tus to the applica- 
tion. 


If not busy status is re- 
turned, issue SWRREC or 
SWRBLK macro call. 


If error status is returned, 
exit from the procedure. 


When write is successful, Issues disconnect acy 
return to step 3 to trans- cording to device 
mit more data to the device. type. , 
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Macro Calls For a Single Interactive Terminal 


Table 5-5 describes the procedures for uSing macro calls in 
communications applications involving only one interactive termi- 
nal which has been configured for synchronous input/output opera- 
tion. | 

Figure 5-1 illustrates the procedure's flow. 


Table 5-5. Macro Call Procedures for Single Interactive Terminal 


1 Issue SGTFIL macro call (see 
Table 5-1) © 
2 Issue SOPFIL macro call (see | 
Table 5-2) with program view 
) bit 1 set to 1, program view © | 


bit 2 set to l. 


To read from the terminal followed by a write to the terminal: 


3 Issue SRDREC or SRDBLK macro Data is read directly 
call. (This effectively into the application 
gives up control until the buffer. | 
read is satisfied.) — 


If error status returned, exit 
from the procedure. 


Issue SWRREC or SWRBLK. (This Data is written 
effectively gives up control directly from the 
until the write is complete.) application buffer 
If an error status is re- 

turned, exit from the proce- 

dure. 


When application processing | Issues a disconnect. 
is complete, issue SCLFIL | 
macro call. 
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$GTFIL 


| 


$OPFIL (PROGRAM VIEW BITS 1 AND.2 = 11) 


$RDREC ($RDBLK) 


$WRREC ($WRBLK) 


YES 
ERROR 


NO 


YES ADDITIONAL 
INPUT 


EXPECTED 


NO 


$CLFIL 


EXIT 


Figure 5-1. Simplified Program Logic for Single 


Interactive Terminal 
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Macro Call Procedures for Multiple Interactive Terminals 


Table 5-6 describes the procedures for using macro calls in 
communications applications involving multiple terminals. 


Figure 5-2 illustrates the procedure's flow. 


Table 5-6. Macro Call Procedures for Multiple Terminals 


Procedure . 
Step Action by Application Program System Actions 
Vice alg Ne tee ats eee Fak Ae oN nee PON he ee eRe ae ra SP nae OBE eto Pe UY eh Ae Sr ee A tee ea ed gh ee A | 
1. Issue $GTFIL macro call to each 
terminal (See Table 5-1). 


Issue SOPFIL macro call to each} Issues asynchronous 
terminal (see Table 5-2 with connect, returns nor- 


program view bit 1 set to l, mal status to the 
bit 2 set to l. © program. : 


To read from a terminal followed by a write to a terminal: 


Will return when a 
read is complete and 
data is available. 
Returns the LFN of 
the first terminal in 
the list for which 
data is available. 


Issue SWIFIL macro call with a 
list of LFNs. (This will ef- 
fectively give up control 
until input is available from 
one or more terminals in the 
list.) 


Issue SRDREC or SRDBLK macro 
call. 


Moves data from sys- 
tem buffer to appli- 
cation's buffer, 
issues another asyn- 
chronous read, and 
returns a normal sta- 
tus to the program. 


5 If an error status is re- 
turned, process the error. 


Issue SWRREC or SWRBLK macro 
can. (This will give up con- 
trol unitl output can be sent 
to terminal.) 


Waits until output can 
be sent; moves data 
from the application's 
buffer to system bu 
fer and issues an 
asynchronous write. 


If additional input is ex- 
pected from any terminal see 
step 3. 
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Procedure | 
Step Action by Application Program |. System Actions 


SEG ee RRO (SERNA RESTS I Me RISE NE IES DD aeRO ED ENR SE To I A EEE ED) ELSE OR PID NE IN oT Re oe OE RE Ce! 
When application processing Issues disconnect. 
is complete, issue SCLFIL 
call. 


$GTFIL & $OPFIL (FILE 1) 


$GTFIL & $OPFIL (FILE 2) FOR $OPFIL, PROGRAM VIEW 
; ; BITS 1 AND 2 ARE SET TO 11. 


SGTFIL & SOPFII (File 2) 


| 


$SWIFIL (ON FILES 1, 2, 3) 


XK 


NOT BUSY — FILE n) 


$RDREC (FILE n) 
YES 
ERROR ; : EXIT 
“NO 
$SWRREC 
(FILE n) 
YES 
ERROR EXIT 
NO 


YES 


ADDITIONAL 
INPUT 
EXPECTED 


NO 


$CLFIL 


EXIT 


Figure 5-2. Simplified Program Logic for Multiple 
Interactive Terminals 
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Binary Synchronous Communication (BSC) 


Binary synchronous communication (BSC), operating in 2780 or 
3780 mode, permits a program to transmit data over communications 
lines from one Level 6 to another Level 6, or a Level 66 system, 
or to a non-Honeywell host system. 


BSC DATA TRANSMISSION CONVENTIONS 
BSC Data Codes 


Data can be in alphanumeric ASCII, alphanumeric EBCDIC, or 
binary format. In communication between Level 6 and a remote 
host, each system must use the Same code set (either ASCII or 
EBCDIC). When EBCDIC is used, the application programs must know 
whether transmission is nontransparent or transparent (1.e., BSC 
control characters are interpreted as data). 


BSC Data Transmission Modes 
There are two BSC transmission modes: basic and advanced. 


In basic transmission mode there is no control byte. The 
absence of a control byte limits the functionality of the proto- 
col (e.g., an application cannot send or receive two message 
blocks or cannot initiate a reverse interrupt (RVI) Sequence). 


In advanced transmission mode there iS a control byte which 
is the first byte in the program's input or output buffer. The 
control byte is used to control the transmission of data and to 
convey information concerning the receipt of data. With the con- 
trol byte the application has almost complete control (subject to 
limitations imposed by the protocol) over the transmission and 
reception of data to and from a remote host. (The control byte 
formats are detailed in Section 10). 


BSC 2780 and BSC 3780 
BSC 2780 is a subset of BSC 3780. Technical differences 
between the two protocols can be Summarized as a set of exten- 


Sions to the 2780 protocol which are as follows: 


o The ability to receive a conversational reply without a 
preliminary bid sequence. 
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o The ability to receive and transmit selected BSC control 
characters. 


From a user's point of view the differences between the two 
protocols can be summarized as follows: 


BSC 2780 


fe) Specified at system building time by the BSC device 
directive. 


O Operates only in advanced mode. 


o The file system supports bidirectional usage of BSC 
2780 communications line. A CLOSE/OPEN sequence must 
be initiated prior to the reversal of the communica- 
tion line. | 


o Specified at system building time by the XBSC 
directive. | 


Oo Operates only in advanced mode. 


o The file system supports interactive usage of the BSC 
3780 communications line. To terminate a transmission 
the application must initiate an EOT sequence by set- 
ting the appropriate bit within the control byte. An 
ETX message transmission sequence can also be termi- 
nated if the other application sends a conversational 
reply. The receipt of conversational reply is indi- 
cated by a bit setting within the transmit control 
byte. The receipt of a conversational reply forces 
the application to issue a file system read order to 
receive the conversational response. The termination 
of a read sequence is indicated by a EOF return code 
(021F) and by the EOT bit being set in the receive 
control byte. (Note that the terms EOF (end of file) 
and EOT (end of transmission) are synonymous). 


Macro Call Procedures for BSC 2780 in Basic Transmission Mode 
The following conditions apply in the use of the file system 
in binary synchronous communications in basic data transmission 


mode: 


o An application cannot send an RVI (reverse interupt) con- 
trol character through the file system. | 


o BSC devices in basic transmission mode can operate only 
in single-buffer mode (see Section 10). 
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o An application can send only the ETB (end of transmission 
block) control character, not the ETX (end of text) 
character. 


o An application can send data in either transparent or 
nontransparent mode. 


o An application can send EOT (end of transmission) con- 


trol characters only after it has issued a SCLFIL macro 
call. 


o BSC operation assumes that the detab option is set off. 


Table 5-7 shows the procedure for using macro calls in 
applications that use BSC in basic data transmission mode. 


Figure 5-3 illustrates a simplified program logic for these 


procedures. 


$GTFIL 


PROGRAM VIEW 
SOPFIL (BITS 1 AND 2 = 01, WRITE) 


$GTFIL 


PROGRAM VIEW 
(BITS 1 AND 2 = 10, READ 


SOPFIL 


SWIFIL 
NOT BUSY a BUSY | 


$RDREC ($RDBLK) 


°F 


YES 


YES 
$CLFIL 


NO 
EXIT 
YES 


Figure 5-3. Simplified Program Logic for BSC 2780 in 
Basic Transmission Mode 
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Table 5-7. Macro Call Procedures for BSC 2780 in 
Basic Transmission Mode 


Procedure 
es Action by Application Program System Actions 


Before a file is first opened 
issue SGTFIL macro call (see 
Table 5-1). 


To read data from a BSC line: 


Issue asynchronous 


connect; returns a 
status to the program. 


Issue SOPFIL macro call (see 
Table 5-2, with program view 
bit 1 set to 1, program view 
bit 2 set to 0. 


Issue SWIFIL macro call to If connect is not 


wait until connection is com- complete, STIFIL re- 
plete and input available. turns a busy status 
If application is to do other or, issues an asyn- 
procesisng (not give up con- chronous read and 
trol) issue STIFIL macro returns a busy status 
call. until read is 


complete. 


Issue SRDREC or SRDBLK macro 
call. | 

If error status other than 
EOF (end of file) is re- | 
turned, exit from the pro- 
cedure. (An EOF status in- 
dicates that EOT (end of 
transmission) control 
character was received, 
indicating sender completed 
its transmission. 


Moves data from system 
buffer to the applica- 
tion's buffer, * and 
again issues an asyn- 
chronous read. If 
there are no errors, 
returns a normal 
Status. 


Test for EOF return Status. 
If status is normal, do 
other processing and return 
to step 3 if more data 
expected. 


If application is to send 
data, issue SCLFIL macro call 
and continue with step 7. 

If application is not to send 
or receive data, issue SCLFIL 
macro call and continue with 
other processing. 
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Table 5-7 (cont). Macro Call Procedures for BSC 2780 in 
Basic Transmission Mode 


Procedure |. 
Step Action by Application Program System Actions 


| To write data to a BSC line: 


i 


Issue SOPFIL macro call (see 
Table 5-2) with program view 
bit.1 set to 0, program view 
bit 2 set to l. 


Issue STOFIL macro call 
test that connection is com- 
plete. 


If file was already opened, and 
closed without a phone hangup, 
the line is still connected; 
STOFIL is not required. 


Issue SWRREC or SWRBLK macro 


call. 
If an error Status is re- 


turned, exit from the proce- 
dure. 


If no writes are pend- 
ing, moves data from 
application's buffer 
to system buffer, 
issues asynchronous 
write to the BSC line, 
and returns a normal 
status. 


If the write is not 
complete STOFIL re- 
turns a busy status. 


Issue SWOFIL macro call to 
wait for completion of pre- 
viously scheduled output. 
Issue STOFIL to continue 
other processing while write 
is in progress. 


When SCLFIL macro 
call is issued, the 

system: sends an EOT 
(end of transmission) 
character if the BSC 
is in send or receive 
mode for that line. 

Sends nothing if the 
BSC line is idle. 


Can now issue another SWRREC 
or SWRBLK macro call, or issue 
a SCLFIL macro call if the 
preceding write macro call was 
the last one, or if SCLFIL 
macro call was issued, and 
more data is to be read from 
the line, return to step 2. 
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Macro Call Procedures for BSC 2780 in Advanced Data Transmission 
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In the BSC advanced data transmission mode, the first byte 
of the application program's input or output buffer is a control 
byte that controls or supplies information about read/write op- 
erations. This byte can indicate, for example, whether data is 
to be transferred in transparent or nontransparent mode, or 
whether an ETB (end of transmission block) or ETX (end of text) 
control character is to be sent or received. (Section 10 details 
the usage of BSC control characters). | 


The following condition applies in using the file system in 
2780 binary synchronous communications in advanced data transm1s~— 
sion mode: 


o It is not necessary to send EOT control characters 
through the control byte since the user must close the 
file in output mode before attempting to read. Ciosing 

the file forces the BSC, if not in idle mode, to send an 


EOT control character. 
Table 5-8 shows the procedure for using macro calls in 
applications that use BSC lines in 2780 advanced data transmis- 
Sion mode. 


Figure 5-4 illustrates the program liege: for these proce- 
dures. 
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Fat: 


$GTFIL 
$GTFIL 


PROGRAM VIEW 
(*) > S$OPFIL = (Bits 1 AND 2 = 01, WRITE) 
(4 )— SOPFIL PROGRAM VIEW 


(BITS 1 AND 2 = 10, READ) 


SWIFIL 


$WRREC ($WRBLK) 


{ 


$SWOFIL 


NOT BUSY 


$CLFIL 


EXIT 


$RDREC $RDBLK) 


$CLFIL YES 


$CLFIL 


Figure 5-4. Simplified Program Logic for 2780 BSC in 
Advanced Transmission Mode 
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Table 5-8. Macro Call Procedures for BSC 2780 in 
Advanced Transmission Mode 


Before the file is first 
opened issue SGTFIL macro 


To read data from a BSC 2780 line: 


Issue SOPFIL macro call (see Issues an asynch- 
Table 5-2) with program view ronous connect; re- 
bit 1 set to 1, program view turns a normal status 
bit 2 set to 0. to the program. 


Issue SWIFIL macro call to If connect is not 

wait unitl connect is complete complete, returns 

and input is available. If a busy status, S$TIFIL 
application is to do other issues an asynchronous 
processing (not give up read, and returns a 
control), issue STIFIL macro busy status unitl the 
call. the read is complete. 


Moves the data from 
the system buffer to 
the application's 
buffer, and again 
issues an asynchronous 
read. If there are no 
error, returnS a nor- 
mal status. 


Issue SRDREC or SRDBLK macro 
call. If error status other 
than EOF (end-of-file) is 
returned, exit from the pro- 
cedure. (An EOF status indi- 
cates that an EOT (end of 
transmission) control 
character was received, de- 
noting that the sender has 
completed its transmission.) 


Test for EOF return status. 
If return status is normal, an 
application.can check for ETB 
or ETX control characters, or 
for transparent or non- — 
transparent processing, and 
return to step 3. 


When EOF or EOT status is re-. 


turned, and more data is ex- 
pected, return to step 3. 
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Table 5-8 (cont). Macro Call Procedures for BSC 2780 in 
Advanced Transmission Mode 


Procedure | 
Step Action by application Program System Actions 


If application is to send 
data, issue a SCLFIL macro 

call and continue with step 
8. If application is not to 
send or receive data, issue 
SCLFIL macro call and con- 

tinue with other processing. 


To write data to a BSC line: 


SOPFIL macro call (see 
5-2) with program view 


set to 0, program view 
to set to l. 


Issue SWRREC or SWRBLK macro 
call. Application can set 
control byte to control trans- 
mission (send ETB or ETX con- 
control characters, or send 


in normal or transparent 
EBCDIC mode). 


If no writes are 
pending, moves the 
data from the applica- 
tion's buffer, issues 
an asynchronous write 
to the BSC line, and 
returns a normal 
status. 


_ 
© 


If the write is not 
complete STOFIL re- 
turns a busy status. 


Issue SWOFIL macro call to 
wait for completion of pre- 
viously scheduled output. 
Issue STOFIL to continue 
other processing while write 
is in progress. 


~ 
a 


If an error status is re- 
turned, close the file and 
exit from the procedure. 


Can now test for RVI-received 
bit in the control byte of the 
record that was just sent. If 
the bit is set on, can either: 


a 
NO 


Close the file and return 
to step 2, or 


Ignore the RVI condition 
and continue to write. 
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Table 5-8 (cont). Macro Call Procedures for 2780 BSC in 


Advanced Transmission Mode 


| Procedure 
Step Action by Application Program System Actions 


13 


Ee eg EE rey ANT ER Oa NST, EAC ORIEN NTT Re OR SEE RR oD 
After the write is complete, 
the application can: 


If there is more data to be 
written, issue another 
SWRREC or WRBLK by return- 
ing to step 9, or 


If more data is expected, 
issue a SCLFIL macro call 
and return to step 2, or 


| Simply issue a SCLFIL macro | : 
call and exit the procedure. . 3 


Macro Call Procedures for BSC 3780 in Advanced Data Transmission 


Mode 


The first byte of the application program's input or output 
buffer is a control byte. The control byte controls or supplies 
information about read/write operations. 


The following conventions apply when uSing the file system 
with 3780 binary synchronous communication in advanced data 
transmission mode: 


O 


The receipt of an optional conversational reply is indi- 
cated by a bit setting in the transmit control byte. 
(This can occur if the application has transmitted the 
last (ETX) block of a message). The application must 
issue a read macro call in order to receive the conver- 
Sational response. 


The termination of a transmit sequence is signaled (via 
control byte) by the transmission of an EOT control 
Character following the last block if a message. Once 
this has been done, a read macro call will be needed to 
receive transmissions from the remote system. (It is not 


necessary to close and reopen the file to turn the line 


around.) 


The termination of a receive sequence is indicated by the 
receipt of an EOF return status or an EOT status in the 
receive control byte. A transmission sequence can be re- 
initiated by issuing another write macro call. (It is 
not necessary to close and reopen the file to turn the 
line around). 
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o A line turnaround (receipt of an EOT) is indicated by an 
O21F EOF return code (and the setting of the EOT bit in 
the receive control byte). At this point the application 
can use the line for data transmission by issuing another 
write request. It is also possible to receive an EOF/EOT 
Status, which indicates the abnormal termination of 
transmit/receive sequence. (This can occur for a variety 
of reasons, most notably hardware problems.) Such an 
occurrence is also indicated by an O021F return code. The 
application can differentiate between these end-of-file 
conditions by considering when the EOF status was re- 
received. For example, two applications agree that the 
last record of a message transmission is demarked by an 
ETX control character. If the transmission is terminated 
by the receipt of an EOT and the last record of the 
transmission was not marked with an ETX control charac— 
ter, the application can assume that the transmitter 
aborted the transmission sequence. If such a condition 
Is detected, the application must close the line by issu- 
ing a close file macro call (all other file system 
requests will be rejected. 


Table 5-9 shows the procedure for using macro calls that use 
BSC lines in 3780 advanced data transmission mode. 


Any 


4 _ Figure 5-5 illustrates the program logic for these proce- 
dures. 


S=21 CBO03 


$GTFIL 


S$OPFIL (BITS 1 AND 2= 11, READ AND WRITE) 


SWIFIL 


NOT BUSY 


$RDREC ($RDBLK) 


ER Yto | 
non $CLFIL 


EXIT 


NO 


NO 


YES 


YES © 


NO 


$CLFIL 


EXIT 


Figure 5-5. Simplified Program Logic for BSC 3780 in 
Advanced Transmission Mode 
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WRITE 
LAST (ETX) 
MESSAGE 


YES 


SWRREC ($WRBLK) 
—WITH EXT 


YES 


ERROR 
$CLFIL 


SWOFIL 


NOT BUSY 


CONVERATIONAL 
REPLY 


YES @ 


RECEIVED 


NO 


YES 
$WRREC ($WRBLK) 


NO 


$WRREC ($WRBLK) 
—WITH ETB 


YES 
ERROR 


$CLFIL 


$WOFIL 


NOT BUSY 


—LAST BLOCK WITH EOT 


ERROR 


YES 


YES © 


NO 


$CLFIL 


Figure 5-5 (cont). 
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Table 5-9. Macro .Ccall Procedures for BSC 3780 in 
Advanced Transmission Mode 


Procedure 
Step Action by Application Program System Action 


1 Before the file is first 
opened, issue SGTFIL macro 
call (see Table 5-1). 


SOPFIL macro call (see Issues an asynchronous 
5-2) with program view connect; returns a 

set to l, program view normal status to the 
set to l. program. 


Issue SWIFIL macro call to If connect is not com- 


Walt Ubeol sonnce.. 2s con— piClCy, Ste Go. Peers 
plete and input is available. a busy status. If 

If application is to do other connect is complete, 
processing (not give up issues an asynchronous 
control), issue STIFIL macro read, and returns a 
call. busy status until the 


read is complete. 


Moves the data from 
the system buffer to 
application's buffer, 
and again issues an 
asynchronous read. If 
there are no errors, 
returns a normal 
Status. . 


Issue SRDREC or SRDBLK macro 
call. If error status other 
than EOF (end-of-file) is 

returned, exit from the pro- 
cedure. (An EOF status indi- 
cates that an EOT (end of 

transmission) control charac- 
ter was received, denoting 

that the sender has completed 
its transmission. 


Test for EOF return Status. 
return status iS normal, the 
application can check for ETB 
or ETX control characters, or 
for transparent or non- 
transparent processing, and 
return to step 3. 


If the applicastion has no 
data to send, issue a SCLFIL 
macro call and continue with 
other processing. | 


6 If the application has data to 
send continue with step 8. 


Table 5-8 (cont). Macro Call Procedures for BSC 3780 in 
Advanced Transmission Mode 


Procedure 


Action by Application Program System Action 


| To write data to a BSC line: 


10 


If no writes, moves 
_ 


the data from the 
- 


If the application wishes to 
send the last (ETX) block of 
message, continue with step 
16. 


Issue SWRREC or SWRBLK macro 
call. Application can set 
control byte to control 
transmisSion of an ETB con- 
trol character. If an error 
status is returned close the 
file and exit from the pro- 
cedure. 


application's buffer 
to the system buffer, 
issues an asynchronous 
write to the BSC line, 
and returns a normal 
status. 


If the write is not 
complete, returns a 
busy status. Returns 

a not busy status when 
the write is complete. 


If application is to do other 
processing (not give up con- 
trol) issue STOFIL. Else, 
issue SWOFIL macro call to 
give up control of the central 
processor until the write is 
completed. | | 


Can now test the transmit con- 
trol byte for the receipt of a 
conversational reply. If the 
bit is set on, initiate 
another read sequence by re- 
turning to Step 3. 


Can now test for RVI-received 
bit in the control byte of the 
record that was just sent. If 
the bit is set on, can 

either: 


Close the file and ini- 
tiate another read 

sequence by returning to 
step 3, or 


Ignore the RVI condition 
and continue to write. 
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Table 5-9 (cont). Macro Call Procedures for BSC 3780 in 
Advanced Transmission Mode 


Procedure | : 
Step Action by Application Program System Action 


a a ° Lo 


transmit, continue with 
Moves the data from 


step 8. 

the application's 
buffer to the system 
buffer, issues an 
asynchronous write to 
the BSC line, and re- 
turns a normal Status. 


If data is expected from the 
remote host, initiate another 
read sequence by returning 

to step 3. 


Transmission and reception se- 
quences are complete. Issue a 
SCLFIL macro call and exit 


SY lt a a 


D eer agers 
Lihue 


16 Issue SWRREC or SWRBLK macro 
call. Application can set 
control byte to control trans- 
mission of an ETX control 

character. If an error status 

is returned close the file and 
exit from the procedure. 


If the write is not 
complete, returns a 
busy Status. Returns 
a not busy status when 
the write is 
completed. 


If application is to do other 
processing (not give up con- 
trol) issue STOFIL. Else 
issue SWOFIL macro call to 
give up control of the 
central processor until the 
write is completed. 


Continue -with common proces- 
Sing of transmit sequence 
by continuing with step 12. 
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SECTION 6 


ASSEMBLY LANGUAGE COMMUNICATIONS USING PHYSICAL INPUT/OUTPUT 


The physical input/output (I/O) interface permits more 
direct user control over communications processing than does the 
file system. 


Used only with assembly language programs, the physical I/0 
interface enables communications applications to: 


o Call appropriate line protocol handlers (LPH) more 
directly through the communications subsystem rather than 
through the file system. 


o Control the data structure, specifically the input/output 
request block (IORB), that directly controls device oper- 
ations and/or characteristics. (See "Data Structures" 
below for description of the IORB.) 


COMMUNICATIONS SUBSYSTEM CONVENTIONS 


The following conventions apply to use of the communications 
subsystem: 


o The I/O request block (IORB) is the standard control 
structure used by an LPH of the communications subsystem. 


o Use the request I/O (S$RQIO) macro call in the application 
program to request an I/O transfer. 


o The B4 register contains the address of the IORB supplied 
by the application program; the IORB contains the logical 
resource number (LRN) of the device to be used. 


o The I/0-specific words of the IORB (I _CT2 through I_DVS) 
are not modified by the line protocol handler. 
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o The communications subsystem maps the hardware return 
status into the software status word I ST of the applica- 


tion's IORB before the line protocol handler gives up 
control. 


Table 6-1 lists the return error status codes that indicate 
logical result of an I/O request. 


USING PHYSICAL I/0 


Two fields within the IORB specify the operation to be 
performed. | 


1. The function code (Table 6-4), indicated by bits C 
through F of I CT2 in the IORB (see Table 6-2), spe- 
cifies the particular operation. 


2. The I_DVS item in the IORB, used with the function code, 
specializes the input/output order. 


For example, in TTY processing, the user can specify a write 
request (function code 1), with or without a carriage return at 
end-of-message, aS indicated by the C- ‘bit of the I DVS a 
Table 7-3). 


To request execution of an I/O operation, the application, 
with the SRQIO macro call, must transfer control to the physical 
I/O interface. At the time of the request the $B4 register must 
contain the address of the IORB being requested. The SRQIO macro 
routine executes the I/O operations, then returns to the request- 
ing application. ; 4 : 


The IORB may define either synchronous or asynchronous con- 
trol. When the IORB specifies synchronous I/O (W (wait) bit in 
I CTl reset), return to the calling application is delayed by the 
Monitor until the I/O operation is complete. On return, the 
return Status field of the IORB, and the $R1 register, will con- 
tain one of the status codes shown in Table 6-l. 


When the IORB specifies asynchronous I/O (W (wait) bit set 
in I CTl), control returns immediately without waiting for I/O 
completion, and the instruction at the return point is executed 
as soon as the system queues the IORB. To obtain the return 
Status (in S$Rl register), when uSing asynchronous I/O, the appli- 
cation should issue a S$WAIT macro call. 


At completion of the I/O operation, the application should 
first check the SR1l register to see that the I/O request was suc- 
cessful. Any error will be defined there. Hardware errors will 
be indicated in the IORB Sor were status word I ST (see 
Table 6-3). 
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Residual range, indicated in the IORB, shows how much of the 
sted data was transferred. With a write request, the resid- 
ange value is the number of bytes remaining to be transmit- 

With a read request, the residual range value is the number 


of bytes remaining to be received. The residual range value in 
I RSR of the IORB is meaningful only when the A-bit in the IST 


item 


(Table 6-3) of the IORB has been set on. 


Table 6-1. Return Status Error Codes for 
Logical Result of I/O Request 


DATA 


Code Number 
(Hexadecimal) 


Meaning 


No error, operation complete 

Request block already busy (T=1) 

Invalid LRN 

Illegal wait 

Invalid arguments 

Device not ready 

Device time-out 

Hardware error, check IORB status word 
(see Table 6-3) 

Device disabled* 

File mark encountered 

Controller unavailable 

Device unavailable ° 

Inconsistent request’ 

EOT received (for BSC 3780 only) 


“IOV & WD FF © 


yO WP OC 


a 


This status is returned on an I/O request when the 
application has disabled the logical resource, and 
for a communications resource, when the result of 
either a connect or disconnect for this logical 
resource iS pending. 


> when these codes are found in I CTl (IORB), or in $Rl 
on a resume after wait, look at I ST (IORB) to iden- 
tify the specific error. The status B is returned 
with every read or write IORB that has been aborted 

- by a disconnect request with queue abort. 


This status indicates illogical device requests: 
read or write before connect, duplicate connect or 
disconnect requests; write after disconnect. 


STRUCTURES 


Two data structures control the interactions among an appli- 


cation program, its line protocol handlers, and the devices it 


uses: 


(1) the input/output request block (IORB), and (2) the 


resource control table (RCT). The IORB is the interface between 
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the application and line protocol handler; the RCT is the inter- 
face between the line protocol handler and its devices. 


This section describes the input/output request block (IORB) 
in general. Later sections describe device-specific fields in 
the IORB for the TTY, VIP, PVE, and BSC line protocol handlers. 


Resource Control Table (RCT) 


The device's resource control table (RCT) contains a channel 
number and level entry, whose values were initially defined at 
system building. The logical resource number (LRN) Supplied by 
the application in the IORB serves as an index into a system 
logical resource table (LRT), which in turn contains a pointer to 
the RCT entry defining the device, as illustrated below. 


USER !IORB LR RCT ENTRY 


CHANNEL 


POINTER 


Thus, with the logical resource number, a line protocol 
handler can indirectly access the RCT entry that defines the 
specific device that the application is to uSe. 


Appendix C describes the resource control table (RCT). 
Input/Output Request Block (IORB) 


The IORB is the standard means for requesting a physical I/0 
service. Generated by the input/output request block macro call 
(SIORB), the IORB contains all the information that an applica- 
tion requesting an I/O service must specify to define the opera- 


tion to be performed... In addition, the IORB includes the 
following: | 


o Logical resource number (LRN) that identifies the I/O 
device being addressed. : 


o Location and size of the buffer to be used for physical 
I/O transfers. 


o Information returned by the line protocol handler to the 
application, concerning results of the I/O request. 
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Figure 6-1 shows the format of the IORB. Table 6-2 defines 
the separate entries in the IORB. Later sections in the manual 
describe the device-specific word (I DVS) and software status 
word I ST for each line protocol handler. 


NOTES: 1. The IORB as described here iS aS it appears for 
short address format (SAF) central processors, 
namely with one-word items. For long address 
format (LAF) processors, the same structure 
would have two-word entries for all pointers. 


2. The labels (I_CT1l, I_ADR, etc.) used in the IORB 
are only for easier presentation. The labels 
cannot be used for programming purposes. 


3. The asterisk (*) in the formulas in the "Ttem" 
column of Table 6-2 is a multiplication sign. 


4. The shaded fields in Figure 6-1 are for system 
use only. The field I FCS is used only by the 
VIP and PVE line protocol handlers. Fields not 
shaded must be initialized by the application 
requesting the I/O operation. 


When the IORB is used with a $RQIO macro call, the device 
named in the IORB should have been initially reserved. The 
logical resource number (LRN) required by the IORB can be 
obtained by issuing a get file information (S$GIFIL) macro call. 
See the description of the request I/O (S$ROQIO) macro call in the 
System Service Macro Calls manual for details. 


O,1 72,3 ),4,5;,6,7,84,94;,A4ByCyODy,EYF 


{ eee, | REQUEST BLOCK POINTER/SEMAPHORE NAME 


atacatecec ote: 
1aPats"oteraVeveTeveve7eeToTeTe707670=6z01070707070707010.0°0, 60,8, 6.0,0,0,0.0.9.0.9,0.0 0.0 ¥.0.¥ 9.0.0.0. ov eee, 


a RETURN STATUS _ [wtetsfotrfo]: | 


1+$AF | CT2 FUNCTION 


2+$AF | ADR BUFFER ADDRESS 


2+2*SAF |_RNG 
3+2*$AF |_DVS DEVICE SPECIFIC WORD 


4+2*$AF | RSR 


R 


5+2*$AF | ST 
6+2*$AF | FCS FUNCTION CODE 1 (VIP AND PVE) FUNCTION CODE 2 (VIP AND PVE) 


Figure 6-1. Communications Input/Output Request Block (IORB) 
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Table 6-2. Contents of Communications Input/Output 
Request Block (IORB) 


| item Label Contents 


er a a ee 
0 through 15 | Depending on the condition of the 
-l | (SAF) S- or R-bits of I_CTl, this word 
| 0 through 31] contains a request block pointer 
(LAF) (R-bit on), or a semaphore name 
(S-bit on). Set by uSer; used by 
system at termination of request. 


through 15] Reserved for system use; one-word 
through 31] pointer (SAF); two-word pointer 


Return status. (See Table 6-1). 


quest using this block is execut- 
ing; it is reset when the request 
terminates. The system controls 
this bit; user should not change 
i oe 


9 (W) Wait bit - set if the requesting 
task iS not to be suspended pend- 
ing the completion of the request 
that uses this block. 


A (U) User bit - user may or may not use 
this bit; system does not change 
hare 

B (S) Release semaphore indicator. 


Values: O=No release, 1=Release, 
on time-out, of item named in 
named in I.RRB. 


C Must be zero. 


D (R) Return request block indicator. 
Values: O=No dispatch, 1=Dispatch 
of request block named in I RRB, 
after timeout of this request. 
System executes SRQTSK, using 
I RRB upon task termination. 


E (D) Delete I/O request block. Values: 
O=No delete, 1=Return memory to 
the pool where IORB is the first 
entry of its memory block. 
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Table 6-2 (cont). Contents of Communications Input/Output 
| , Request Block (IORB) 


SAF I CTl F T/O bit - must be set. 
(cont) (cont) 


1+SAF LCT? 0 through 7 Logical resource number (LRN); 
identifies device to be used. 


Item 


Reserved for later use. 


Byte index; O=buffer begins in 
leftmost byte of word, l=buffer 


begins in rightmost byte. 
Reserved for system use. 


Reserved for later uSe. 


C through F Function code. See Table 6-4. 


Buffer address; SAF mode, l-word 
pointer. 


2+SAF I_ ADR 


0 through 15 


Buffer address, LAF mode; 2-word 
pointer. 


0 through 31 


0 through 15 
I DVS 0 through 15 Device-specific information. | 


I_RSR 0 through 15 |] Residual range. Indicates the 
number of bytes not transferred. 
I ST |} O through 15 


Filled in by the system on comple- 
tion of the order. 
I FCS | 0 through 7 
8 through 15 


2+2*SAF Range — number of bytes to be 


transferred. 


I__RNG 


34+2*SA 


4+2*SAF 


Status word. Reflects the mapping 
of the hardware status into soft- 
ware status format. See Table 6-3. 


5+2* SAF 


Function code 1 (VIP and PVE only), 
Function code 2 (VIP and PVE only), 


6+2*SAF 
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IORB Software Status Word (IST) 


The line protocol handler maps into the IORB software status 
word I ST (see Table 6-3) the return status of the hardware, 
obtained from the device status field R_STTS of the resource con- 
trol table (RCT). (Appendix C describes the resource control 
table.) 


The bit settings in the software status word I ST indicate 
to the application the status of the hardware, as shown in 


The meanings of bit settings in the software status word 
I ST for specific devices are shown in tables in later sections 
that describe the line protocol handlers for those devices. 


Table ee Software (I ST) Status Codes 


Meaning When Bit Set On 


PVE read error 


VIP, 


Data service rate error 


Lost line bid; RVI received (BSC only) 


Communication control block service error 


No stop bit on character input (TTY only); con- 
versational reply received (BSC 3780 only) 


Long record 


For BSC: O=ITB/ETB received; 1=ETX received 
For VIP and PVE: poll failure 


For VIP and PVE: NAK limit reached 


For VIP and PVE: Checksum or parity error limit 
reached 


Nonzero residual range | 


Phone disconnect. 


BSC only: End-of-transmission (EOT) received 
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Table 6-3 (cont). Software (I_ ST) Status Codes 


Meaning When Bit Set On 


For VIP: page overflow 
For BSC: transparent message received 


For VIP: busy or not available 
For BSC: NAK limit reached 


Nonexistent resource; bus parity error; fatal 
uncorrectable memory error 


COMMUNICATIONS FUNCTION CODES 


All line protocol handlers perform similar functions for the 
devices and applications they service. These functions are per- 
formed by the line protocol handler's request and interrupt pro- 
cesSing codes. 


An application can request specific functions by providing a 
function code in the IORB supplied when it requests I/O service. 
The application uses the last four bits of its IORB's I CT2 entry 
(see Figure 6-1) to enter the function code for the functions 
Summarized in Table 6-4. 


The connect and disconnect functions may be used with non- 
communications devices (processed aS no-ops) for program compat- 
ibility; i.e., no matter how connected to the Level 6 system, all 
TTY devices and noninteractive (e.g., card reader and printer) 
devices can be controlled by the same application program. This 
is useful for program development and test purposes. 7 


Table 6-4. Communications LPH Function Codes 


Function 
Code in 
IORB Communications Function 


Wait online 
Write 

Read 
Connect 
Disconnect 


Wait Online Function (Code 0) 


The wait online function, is used to synchronize task opera- 
tion with device availability, and allows a caller to wait until 
a device becomes ready for use, or until a specific time interval 
has passed before using it. 
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When an LPH receives a service request from a task using the 
wait online function code in the IORB that is supplied (0000 in 
the last four bits of I CT2), and the device is not ready, the 
driver sets a timer for 5 minutes and suspends. When the LPH is 
reactivated, either by a ready interrupt from the device or by a 
time-out, it deactivates the timer, checks the device-ready bit 
in the hardware status word and places a 0 or 6 value in the 
return status field of the IORB depending on the condition of 
that bit. See the return status codes for the S$RQIO (request 
I/O) macro call; the rightmost hexadecimal character is placed in 
the return status field. See Table 6-l. 


The wait online function should not be issued to a device 
that 1S currently ready for use unless it is expected to become 
temporarily unavailable. 


NOTE: For compatibility with higher level languages, using 
the wait for operation complete macro call (SWATT) 
results in an immediate return of 0. 


Write Function (Code 1) 


This function allows data to be written to a specific 
device. When a line protocol handler (LPH) receives a write a 
request, it transfers the indicated data from the application's 
buffer to the device, according to the specifications Supplied in 
the device-specific word of the application's IORB. 


Read Function (Code 2) 


This function allows data to be read from a specific device. 
When the LPH receives a read request, it transfers data from the 
device to the application's buffer, according to the information 
supplied in the device-specific word of the application's IORB. 


‘Connect Function (Code A) 


The connect function provides a logical and physical connec- 
tion between an application program and a communications device. 


As a logical function, the connect function is a request to 
use the specified communications device. If that resource is 
being used, an error return results. In that case the applica- 
tion must determine whether that resource is sharable (as estab- 
lished by the installation's procedures), and proceed 
accordingly. 


As a phySical function, the connect function establishes a 
physical path to the communications device associated with the 
specified logical resource number (LRN). This implies, when the . 4 
device is to be connected over a switched line, that the system Ne 
software should answer the telephone on the line associated with 
that device. The request times out after five minutes. 
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If the connect function is not completed, the system will 
not process any requests for communication devices, and will 
return an error status. 


The connect function must be requested before any other 
function, Since communications devices are configured into the 
system in a disconnected state. 


Disconnect Function (Code B) 


The disconnect function provides both the logical (normal 
and abnormal) and physical disconnection between the application 
and a communications device. 


As a logical function, the disconnect function indicates 
that the use of the designated device is to be terminated. 


For a logical disconnect, issue a disconnect request (func- 
tion code B) with a queue abort (E-bit in I DVS set on), and no 
phone hangup (F-bit in I DVS set on). (See Table 7-3.) At this 
point, any pending read or write requests are returned to the 
application program with a B status (device unavailable). Con- 
tinued use of the device requires that the application program 
issue a connect. 


As a physical function, the disconnect function must Specify 
the physical disconnection of a line. | 


Requesting Communications Functions 


The following is the sequence for an application to request 
a transaction with a communications resource: 


1. Set up an IORB with the connect function (code A). 


2. Call the physical I/O interface (request I/O macro call 
SRQIO). 


3. When the connection is complete, supply the appropriate 
IORBs for those operations that the application will 
perform. 


4. Perform the functions, e.g., read, write, and/or wait 
online required by the application's logic. 


5. When application processing is complete, supply an IORB 


with the disconnect function (code B) and issue the 
request I/O macro call (SRQIO) to execute the function. 
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The input/output request block (S$IORB) and request I/O 
(SRQIO) macro calls provide direct communication from a communi- 
cations application to the appropriate line protocol handler 


(LPH). -The System Service Macro Calls manual describes these and 
related macro calls in detail. 
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SECTION 7 


TTY LINE PROTOCOL HANDLER 


The TTY line protocol handler Supports asynchronous terminal 
devices, generically classified as teleprinter-compatible (TTY), 
that include certain ASR, KSR, and visual information projection 
(VIP) terminals. | | 


A baSic TTY terminal consists of either a printer and key- 
board or a VIP 7100/7200/7800 display and keyboard. (Paper tape 
is not Supported.) Each type of TTY terminal has an asynchronous 
Communications interface that permits operation at up to 9600 
baud. 


GENERAL TTY LINE PROTOCOL HANDLER OPERATION 
TTY Message Formats 


Figure 7-1 illustrates TTY message formats. On input, the 
application receives only the text portion of the message. On 
output messages, the application can control print format with a 
control byte that is specified as the first character of the 
output buffer (in the IORB device-specific word I DVS, described 
later). At connect, read, or write, the application can, with 
the I DVS word, dynamically specify which message format is to be 
used. | 
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DYNAMIC 
CONTROL, TEXT OUTPUT 
BYTE | 


TEXT | OUTPUT 


DYNAMIC 
* CONTROL OUTPUT 
BYTE | 


OUTPUT 


Figure 7-l. rTy Message Formats 
TTY Character Mode and Buffered Mode Transmission 
TTY CHARACTER MODE 
Transmission for all TTY terminals is usually in character. 
mode (one character at a time), a characteristic of the hardware 


that provides that: 


o The TTY line protocol handler does all editing of data 
before any transmisSion. 


o Multiple input lines are not allowed at the same time. 
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TTY BUFFERED MODE (VIP 7200 AND 7800) 


For VIPs 7200 and 7800 only, the buffered mode, available as 
a hardware option, permits: . 


o The TTY line protocol handler to process multiple lines 
of input at the Same time. 


o The operator to do local editing of data before it is 
transmitted. 


o The application to instruct the TTY line protocol handler 
not to edit input data. 


Buffered mode permits the TTY line protocol handler to pro- 
cess a write order while a read order is pending. A "quasi full 
duplex" operation gives the line protocol handler the ability to 
have the application send to the terminal, sequences that cause 
the terminal to send information back to the application's 
buffer. 


Buffered quasi full duplex operates as follows: 


1. When the channel control program (CCP) of the multiline 

| communications processor (MLCP) is currently processing 

¥ a write order to the terminal, a subsequent read or 
write operation is not given to the CCP until the cur- 
rent write order completes. 


2. When the CCP is procesSing a read order and the next 
following order is a write order, that write order is 
processed while the read order is active. 


3. When the write order (2 above) completes and the read 
order has not yet completed, a subsequent read or write 
order will not be processed until the read is completed. 
When the read order is completed before the write order, 
actions in 1 above take effect. 


4. When the read order is completed, the line protocol 
- handler returns to its original state, i.e., no orders 
pending. The line protocol handler can initiate read or 
write orders to the CCP. 


VIP 7200 AND 7800 HARDWARE SWITCH OPTIONS WITH CHARACTER 
OR BUFFERED MODE 


The TTY line protocol handler supports the following VIP 


7200/7800 hardware switch options for character mode or buffered 
( mode as follows: 
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Character Mode 


Character/buffered mode switch 
on character mode. 


Buffered Mode 


Character/buffered mode switch 
on buffered mode. 


Parity switch on even. Parity switch on even. 
Full/half duplex switch on 


Full/half duplex switch on 
Full. 


full. Page/line switch as 
necessary. End-of-message 
(EOM) character internal 
Switch set to ETX or EOT (not 
to CR). 


VIP 7200 AND 7800 FUNCTION AND CONTROL KEYS 


Function and control keys on the VIP 7200 and 7800 are sup- 
ported only in buffered mode. | 


When isSSuing a write request that will cauSe an automatic 
response by the terminal, the application must first issue an 
asynchronous read request, then issue a write request that con- 
tains a control message to the terminal. 


TTY Line Protocol Handler Time-Out Intervals 


Table 7-1 lists the TTY line protocol handler's time-out 
intervals for the LPH functions. _ 


Table 7-1. TTY Line Protocol Handler Time-Out Intervals 


Line Protocol | 7 | 
Handler Function Time-Out Interval 
ELLIE ES OE EE OL ES LET RS [LEAL aM Ee NS EAL EE RET EE RE a I EOE NE EO ES OE OE I AE ASE RN EE Oe OP a EE 


Connect Five minutes 


Read five minutes 


of the first 
the message; 


after receipt 


Character mode: 
| | character of 


five minutes after the 
line protocol handler 
receives the request. 


Buffered mode: 
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USING THE TTY LINE PROTOCOL HANDLER 
TTY-Specific IORB Values 

The TTY-specific IORB item I CT2, device-specific word 
I DVS, and software status word I ST are shown and defined in 
Tables 7-2, 7-3, and 7-4, respectively. Section 6 describes the 
general form of the IORB. 


Table 7-2. Function Codes in I CT2 of the IORB 


Function 
Code Definition Use 


Wait online | Used by the line protocol handler 


Write to complete the description of 
Read the requested I/O function 
Connect 

Disconnect 


Table 7-3. TTY Device-Specific Word I DVS in the IORB 


Bit Bit 
Number | Setting 
ee ee eee 

0 

t 


For connect call only (function code A) 


Meaning of Bit Setting 


Must be Zero. 


Must be. zero. 


Do not use Auto Call Unit. 
Use Auto Call Unit. 
Must be zero. 


First byte in buffer on output is a control 
byte. 


First byte in buffer on output is a data byte. 


For read call only (function code 2) 
Input data is in nontransparent mode. 
Input data is in transparent mode. 


Must be zero. 
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Table 7-3 (cont). TTY Device-Specific Word I DVS in the IORB 
Bit 


Bit |. | 
Number | Setting Meaning of Bit Setting 


For write call only (function code 1) 


Stop output immediately on detecting a BRK 
received from the terminal. 


Continue output when BRK detected. 


Must be zero. | 


Must be zero. 


For read call only (function code 2) 


G Do not echo keyboard input. 


5s 


Al Echo keyboard input. 


For read and write calls (function codes 2, 1) 


No LF (line feed) at end of message. 


LF (line feed) at end of message. 


CR (carriage return) at end of message. 


No CR (carriage return) at end.-of message. 


Data transfer is in character mode. 


Data transfer is in buffered (block) mode. 


For disconnect call (function code A) 
E Abort (dequeue) all IORBs on the request queue. 


Process outstanding requests on the request 
queue. 7 


F Hang up phone after disconnect. 


Do not hang up phone after disconnect. 
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Table 7-4. TTY Software Status Word I ST in the IORB 


Meaning When Bit Set to 1 
ATA CARE aa MR RP Oo OEP I EE OR IO TEN De OLDE EY 
mn 


Data service rate error 
N/A 


Communications control block (CCB) service 
error 


No stop bit in character input 


Long record 

N/A 

N/A 

N/A 

Nonzero residual range 

Phone hang-up 

N/A 

N/A 

N/A 

Fatal error: bus parity or memory error 
Although nonexistent resource, bus parity, and 
uncorrectable memory errors are combined in 
bit F, each occurrence is noted separately in 


the resource control table (RCT). See 
Figure C-l. 


Control and Characteristics of TTY Input Data 
This subsection describes user control over the character- 


istics of TTY input data, and applies to eherecrer mode process- 
ing unless otherwise noted. 
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TTY CONTROL BYTE (INPUT) 


The description of the TTY control byte for output (see "TTY 
Control Byte (Send)" below) applies also to the TTY line protocol 
handler's control byte for input. | 


TTY NONTRANSPARENT INPUT 


TTY input is nontransparent when the application sets to 0 
bit 5 of the IORB's device-specific word I DVS (Table 7-3). 
Input is accepted until the end-of-range or a CR (carriage 
return), ETX (end of text), or EOT (end of transmission) control 
character, whichever is first, is reached. The line protocol 


handler does not transmit the CR, ETC, or EOT control character 
aS part of the message. 


TTY TRANSPARENT INPUT 


TTY input text iS transparent when the application sets to l 
bit 5 of the device-specific word I DVS at read time (Table 7-3). 
All input data, including and control characters, is stored in 
the buffer until end-of-range is reached. 


TTY LINE FEED (LF) AND CARRIAGE RETURN (CR) INPUT SEQUENCE 


The application can specify at read time a sequence of LF 
and CR characters, with the B- and C-bits of the IORB's device- 
specific word I DVS, as indicated in Table 7-3. When the message 
is received successfully, the specified character combinations 
are retransmitted back to the terminal. 


KEYBOARD INPUT CHARACTER AND LINE CONTROL 


When an input character with a parity error is received, the 
line protocol handler sends a BEL character back to the terminal. 
The user must then retype that input character if it is to be 
included in the text being sent to the application. 


The user can correct or delete erroneous characters or lines 
and can declare control characters to be data characters, as 
described below. 


To correct one or more characters in the current line, 1.e., 
before the CR is pressed, press the @ key. This deletes the 
character that immediately preceded the @ character, and displays 
the @ symbol. Each succeeding @ entry deletes another character, 
moving from right to left to the beginning of the line. 


To delete the current line, i.e., before the CR is entered, 
press and hold the CTRL (control) key and press X. This deletes 
the current line, displays the message *DEL* on the next line, 
and results in a carriage return. The user can then enter a cor- 
rect line. 
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To declare a control character (e.g., @, CTRL X, CR, and ) 
be accepted as a data'character (transparent mode) press the back 
Slash ( ) key before entering that control character. The system 
interprets the back slash as an eScape character. In transparent 
mode , all input characters are data characters and have no edit- 
ing functions. 


TTY DISPLAY OF INPUT CHARACTERS 


The user can cause an input character to be sent back to the 
terminal (displayed on the screen or typed on the console) by 
setting to 1 the A-bit of the device-specific word I DVS (Table 
7-3). For full duplex printers, the application need specify 
that characters be returned only when they are to be echoed by 
the system software. 


TTY INPUT IN BUFFERED MODE (VIP 7200 AND 7800 ONLY) 


When the application at connect time sets to 1 the D-bit of 
the device-specific word I DVS, input is accepted until an ETX or 
EOT control character or end-of-range is encountered. 


When the application sets bit 5 of I_ DVS to 1 at read time, 
TTY input in buffered mode is transparent, i.e., there is no 
editing. When the bit 5 is set to 0, TTY input in buffered mode 
is nontransSparent, i.e., control characters are edited. 


As in character mode, the application can specify an LF and 
CR sequence, as deScribed above under "Line Feed (LF) and Car- 
riage Return (CR) Input Sequence." 


Control and Characteristics of TTY Output Data 


This subsection describes user control of the character- 
istics of TTY output data and is applicable to character-mode 


processing unless otherwise stated. 


TTY CONTROL BYTE (SEND) 


The TTY line protocol handler's control byte, included as 
the first character of the application's buffer, controls the 
message's head-of-form sequence. At connect time, the applica- 
tion specifies the control byte by setting to 0 bit 4 of the 
IORB's device-specific word I DVS (Table 7-3). 


Figure 7-2 shows the format and content of the TTY control 
byte. 
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BITS 0 THROUGH 2: 
NOT USED 


BIT 3: 


0 = DO NOT GENERATE A 
HEAD-OF-FORM SEQUENCE 


1 = GENERATE HEAD-OF-FORM 
SEQUENCE CONSISTING OF 
LF, DL ISSUED THREE TIMES 


BITS 4 THROUGH 7: 
NOT USED, MUST BE ZERO 


Figure 7-2. Control Byte for TTY Line Protocol Handler 
END-OF-MESSAGE (EOM) SEQUENCE ON TTY OUTPUT 


The EOM sequence is controlled by the B- and C-bits of the 
IORB's device-specific word I DVS (Table 7-3), as specified by 


i i 1 ? as 7? Tad awa wm ee eens | 22. eh SSD. a : 
the application at WELT e Cine. The TTY line prococesa nanuser 


sends an EOM sequence according to the following B- and C-bit 
values: 


I_DVS Bits 
B C EOM Sequence 
0 0 CR, DEL 
0 ug None 
1 0 LF, CR, DEL 
1 1 LF, DEL 


At read time, the application can specify the same B- and C- 
bit values in order to send an EOM sequence back to the terminal 
when the message is successfully received. 


TTY DETECTION OF BRK CHARACTERS 


When the application sets to 0 bit 7 of the device-specific 
word I DVS at write time, the line protocol handler will immedi- 
ately stop all output when it detects a BRK key character in the 
input stream from the terminal. The line protocol handler 


ignores the BRK character when bit 7 is set to l, until the write 


order is completed. 
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TTY OUTPUT IN BUFFERED MODE 


Control and characteristics for TTY output in buffered mode 
are the same as described above for character mode. However, in 
processing in buffered mode (VIP 7200/7800 only) the line 
protocol handler processes all physical I/O requests in the same 
sequence as they are received. If there is already an outstand- 
ing read request, only a subsequent write request can be ini- 


tiated before the read request is satisfied or the time-out for 
that read request is elapsed. 
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SECTION 8 


VIP LINE PROTOCOL HANDLER 


The viP line protocol handler supports synchronous VIP 
(visual information projection) terminals, and the synchronous 
receive-only printers (ROP). 


The basic VIP comprises a cathode ray tube (CRT) display 
screen and keyboard, with a synchronous communications interface, 
with operating speeds as follows: 


VIP Baud Rate 
7760 9600 

7700R Up to 9600 
7700 Up to 4800 


GENERAL VIP LINE PROTOCOL HANDLER OPERATION 


Software Functional Support for the VIP 


The following VIP line protocol handler software functions 
Support the basic VIP terminal: 


O 


O 


O 


Poll and select communications procedures 

Nonpoll communications procedures 

Point-—to-point and multipoint configuration support 
Switched and private line operation 

Auto-answer for switched network operation 


Modem, direct connect, and modem bypass interconnection 
modes 


Message transfer to and from a CRT (1920-character 
format) 
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o Fully addressable CRT entry marker control 
o Pre-editing (control byte) and post-editing (I_DVS) 


o Transfer of hardware function code to and from the 
application 


o Error recovery procedures 

The following functions support added terminal options: 

o User-controlled CRT forms mode 

o Message transfer to receive-only printer (ROP) 
User-Supplied Software Functions for VIP Support 


The application program must supply the following functions 
to support data exchange between the VIP and the application: 


o User-specified device arguments, (polling interval, and 
at system building, station addresses) 


For messages to the VIP terminal, the application should provide: 
o Optional; hardware function codes (1, 2) 
o Complete message text 


o Optional; pre-editing and post-editing characters within 
message text 


o Mandatory; complete forms definition message text for 
forms mode 


For messages received from the VIP, the application must provide: 
o Interpretation of hardware function codes (l, 2) 
o Message proceSSing 


 o Interpretation of format codes (LF, CR, HT) in the 
message text | 


VIP Time-Out Intervals 


Table 8-1 lists the time-out intervals used by the line 
protocol handler for the connect, read, and for ROP write func- 
tions for the listed devices. The line protocol handler will 
try and retry the connect, read, and write functions until the 
indicated time-out period has elapsed. 
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Table 8-1. VIP Line Protocol Handler Time-Out Intervals 


Time-Out Interval (Device) 


Connect 5 minutes Communications Supervisor 
Tries connect one | Nonpolled 
time, returns B 
status 
Tries five times | Polled 
Tries Tributary station 
indefinitely 

Read None 


According to the settings 
of bits 0 and 1 in I_DVS- 
(see Table 8-3) 


10 minutes 


Indefinite 


Write (ROP) 15 seconds Screen (nonpolled) 


1 second Screen (polled) 


21 seconds TN1200, 7717 


95 seconds ™N 300, 7714, 7716 (300 baud) 


180 seconds TN300, 7714, 7716 (150 baud) 


190 seconds TN300, 7714, 7716 (110 baud) 


190 seconds TTY 35 


TTY 33, 


NOTE: Based on 1920-character display screen. 


USING THE VIP LINE PROTOCOL HANDLER 
VIP-Specific IORB Values | 

The VIP-specific input/output request block (IORB) item I CT2, 
device specific word I DVS, and software status word I ST, are 


shown in Tables 8-2, 8-3, and 8-4, respectively. Section 6 
describes the general form of the IORB. 


8-3 CB03 


Table 8-2. Function Codes in I CT2 of the IORB 


Function 
Code Definition 


ol Naa a a a a 
Wait online | Used by the line protocol handler 

to complete the description of 
Write the requested I/O function. 


Read 
| Connect 


Disconnect 


Table 8-3. VIP Device-Specific Word I DVS in the IORB 


Bit Bit 
Number(s) |Setting Meaning of Bit Setting 


For connect call only (function code A) 


00 Time-out after 10-minute interval. 

O01 No time-out on read requests (i.e., 
indefinite). 

10 Immediate time-out, no time-out interval. 

11 Reserved for later use by the system. 


Do not use Auto Call Unit. 
Use Auto Call Unit. 
Set cursor to home position on page overflow. 


Do not set cursor to home position on page 
overflow. 


Include control byte in first byte of buffer. 


Do not include control byte in buffer. 


Logical poll interval (polled lines only): 
Poll continuously. 
l-second poll interval. 


2-second poll interval. 
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Table 8-3 (cont). VIP Device-Specific Word I DVS in the IORB 


Bit Bit 
Number(s) | Setting Meaning of Bit Setting 


3-second poll interval. 


4-second poll interval. 


5-second poll interval. 

15-second poll interval. 

30-second poll interval. 

There are no hardware function codes. 


There are hardware function codes. 


For write call only (function code 1) 


No LF (line feed) at end of message. 
Issue LF (line feed) at end of message. 
Issue CR (carriage return) at end of message. 


Do not issue CR (carriage return) at end of 
message. 


Abort (dequeue) all IORBS on the request 
queue. 


Process all outstanding requests on the 
request queue. 


Hang 1p phone after disconnect. 


Do not hang up phone after disconnect. 
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Table 8-4. VIP Software Status Word I ST in the IORB 


Bit | Meaning When Bit Set to l 


0 N/A 
1 Read error 


2 Data service rate error 


3 N/A 

4 Communications control block (CCB) service 
error 

5 N/A 

6 Long record 


7 Poll failure 


8 NAK limit reached 


Excessive checksum/parity errors 


9 
A | Nonzero residual range 
B Phone hang-up 

C N/A 

D Gneorceetabie page overflow 


E Busy received 


F Fatal error: bus parity or memory error 


Although nonexistent resource, busS parity, and 
uncorrectable memory errors are combined in 


bit F, each occurrence iS noted separately in 


the resource control table (RCT). 


See 


Figure C-l. 


VIP Polling Options 


Polling (the line protocol handler's continuous request to 


the VIP terminal on a polled line for data) 


is subject to two 


kinds of control, a polling interval and a poll duration. 


The application, at connect time, must specify the arguments 
for the poll interval and poll duration, by setting the appropri- 
ate bits in the IORB's device-specific word I DVS (Table 8-3). 
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VIP POLL INTERVAL 


The VIP poll interval specifies the minimum period of time 
between each successive request (poll) by the line protocol 
handler for data from a VIP terminal. The line protocol handler 
will poll the VIP once for each read request, and when the 
request is not satisfied, again after the specified poll period 
elapses. 


For example, with a 1-second poll interval, the line proto- 
col handler will issue the same read request every second. For a 
zero poll interval, the line protocol handler will poll the VIP 
continuously. 


The application specifies the poll interval according to the 
bit settings of the bits 5, 6, and 7 in the device-specific word 
I DVS of the IORB, as shown in Table 8-3. 


VIP POLL DURATION (TIME-OUT) 


Poll duration, or the time-out interval, is the maximum time 
that the line protocol handler will wait for polled data from the 
VIP, before discontinuing the read attempt and read request. 
Possible time-out intervals are immediate (i.e., after only one 
poll); 10 minutes; and indefinite (i.e., the VIP is polled con- 
tinuously, with no time-out, until requested data is received). 
The application specifies the poll duration or time-out interval 
with the bits 0 and 1 in the device-specific word I DVS, accord- 
ing to the bit values shown in Table 8-3. 


VIP LINE PROTOCOL HANDLER POLL FUNCTIONS 


Within the controls specified in the poll argument values by 
the application, the line protocol handler provides all necessary 
polling functions, e.g., how terminals share a common line, or 
which terminal is processed next, etc. When the application 
bypasses these line protocol handler poll functions, i.e., by 
specifying immediate time-out after only one poll, the applica- 
tion must then provide for proper operation and coordination 
among all terminals on the line. 


Control and Characteristics of VIP Input (Keyboard/Screen) 
VIP INPUT MESSAGE HEADER 
The line protocol handler strips the message header from the 


input data, except for the hardware function codes, and does not 
include the header in the application's buffer. 
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VIP HARDWARE FUNCTION CODES | | ee, 


VIP hardware function codes are listed in the appropriate 
hardware device manuals. 


These codes, provide a special message labeling capability 
to be used by the application. 


The application can include two function codes in the mes- 
sage header of each text message to or from a terminal by setting 
to 1 bit 8 of the IORB's device-specific word I DVS (see 
Table 8-3) at connect time. The line protocol handler then 
inserts the two user-specified hardware function codes at read 
time into the IORB's item I_FCS (see Figure 6-1 and Table 6-2). 


VIP INPUT DATA 


The line protocol handler places into the application's buf- 
Fer all data, between the STX and ETX controi Characters, 
received from the VIP terminal. The data is inserted into the 
buffer in 7-bit ASCII, with the most significant bit always zero. 
The LPH strips the ETX and LRC (longitudinal redundancy check 
character, see Appendix A) from the data and does not include 


them in the buffer. 
Control and Characteristics of VIP Output oe 


This subsection pertains to VIP output and is applicable to 
the keyboard, display screen, or read-only printer (ROP) as 
indicated. 


VIP OUTPUT MESSAGE HEADER © 


The VIP line protocol handler supplies the output message 
header, but not the hardware function codes. Those may be sup- 
plied by the application as described above under "VIP Hardware 
Function Codes." 


At write time, when the hardware codes are specified, they 
are placed in the I_FCS item of the IORB. When they are not 
specified, i.e., the bit 8 of I DVS set to 0 at connect time, the 
line protocol handler will insert two spaces, instead ‘of function 
codes 1 and 2, into the I FCS item (see Figure 6-1 and 
Table 6-2). 


VIP CONTROL BYTE (SEND) 


The VIP control byte is specified when the application sets 
to 0 the bit 4 of the device-specific word I DVS at connect time. 
The line protocol handler then places the control byte as the es 


First character of the application's buffer. | Oe. 
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The control byte controls the output form feed sequence 
according to its bit settings as shown in Figure 8-1. The line 
protocol handler provides the output ETX control character and 
the LRC (longitudinal redundancy check) character. 


0 1 2 3 4 5 6 7 
P}+ fo} viz} ziz] z 


RESERVED (NOT EXAMINED) 
Y=0 

DO NOT ISSUE FORM FEED SEQUENCE 
Y= 

ISSUE FORM FEED SEQUENCE 
ZZZZ 


NUMBER OF LINES TO SKIP BEFORE PRINTING (BINARY) 
(E.G., IF ZZZZ=0100, VIP LPH WILL PERFORM 
4 FF SEQUENCES) 


R 


Figure 8-1. VIP Control Byte (Send) 


VIP OUTPUT DATA 
The application's output data must be 7-bit ASCII (the 


eighth bit is ignored). Any ASCII control characters, if 
included in the application's data, are not transmitted. 


For keyboard/display screens, the line protocol handler 
sends a CR, LF sequence when the application's buffer contains 
the hexadecimal character X'05' (NL). . 

For the read-only printer (ROP) the line protocol handler 
sends a CR, LF sequence (according to the type of ROP) shown 
below, when the application's buffer contains the X'05' character 
(NL). | 

ROP Type Line Sequence 
TN1200, 7717 CR, LF, 36 DELs 
7714, 7716, TN300, TTY 35 CR, LF, 9 DELS 


TTY 33 CR, LF 
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VIP KEYBOARD/SCREEN OUTPUT EDITING CONTROL | oe 


The line protocol handler sends LF and CR editing characters 
for VIP keyboard/screen devices according to the values of the B- 
and C-bits of the device-specific word I DVS (Table 8-3). The 
application specifies these bit values at write time to send the 
CR and LF characters, as follows: 


I DVS Bits Editing 
Characters 
B C Sent 
0 0 CR 
0 I None 
i O- LF, CR 
ak 1 LF 


VIP RECEIVE-ONLY PRINTER EDITING SEQUENCE 


The line protocol handler sends an output editing character 
sequence for the receive-only printer (ROP) according to the values 
of the B- and C-bits of the device-specific word I DVS (Table 
8-3). The application specifies these bit values at write time 
to send the ROP output editing sequence, according to the ROP 
‘type, as shown in Table 8-5. 


Table 8-5. VIP Receive-Only Printer Editing Sequence 


I DVS Bits 
ROP Types B C Output Editing Sequence 


TN1200, 7717 | CR, 36 DELs 


7714, 7716, TN300, TTY 35 CR, 9 DELs 


LTY 33 


TN1200, 7717 LF, CR, 36 DELs 
7714, 7716, 1N300, TTY 35 LF, CR, 9 DELs 
TTY 33 LF, CR 

™ 1200, 7717 | a : 36 DELs 
7714, 7716, TN300, TTY 35 .F, 9 DELs 


TTY 35 
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VIP RECEIVE-ONLY PRINTER FORM FEED SEQUENCE 

The VIP line protocol handler sends an output form feed 
sequence according to the ROP type and whether the ROP has the 
hardware form feed option, as shown in Table 8-6. 


Table 8-6. VIP Receive-Only Printer Form Feed Sequence 


ROP Type Output Form Feed Sequence 
Without form feed feature 


TN1200, 7717 LF, 36 DELs (both three times) 


7714, 7716, TN300 |LF, 9 DELS (both three times) 


LF, 9 DELS (both three times) 


TTY 35 


TTY 33 LF, three times 


With form feed feature 


7717, TN1200 FF, 240 DELS 


7714, 7716, TN300 | FF, 65 DELs 


TTY 35 FF, 65 DELs 


ERROR PROCESSING BY VIP LINE PROTOCOL HANDLER 


Table 8-7 lists the errors reported by the VIP line protocol 
handler for any VIP configuration. It also lists corresponding 
return status error codes (see Table 6-1), corresponding bits in 
the VIP software status word I ST (see Table 8-4), and possible 
recovery actions. 


Table 8-8 lists the MLCP-specific error condition according 


to particular VIP configurations, the corresponding error codes, 
and bits in the I ST. 
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Table 8-7. Errors Reported by VIP Line Protocol Handler 


i _ST 
ee 
As a nine times 
reported 
2. ee 


Posted Error 
Return Status’ 


Error Condition 


a a re ee al 
Error during open 


"Not available" 


SSAA arr ER 
7 


Page overflow not 
corrected 


Invalid range in IORB 
Read time-out 


NAK limit reached 


yacal 
~_ eww 


10-minute retry 


mr! 
het 


Purged due to imme- None 

diate close 

Fatal error at inter- None 

rupt level 
0 eee 2 Not fatal 
7 (receive) 2y 
— None (ACK sent to VIP) |Not fatal 


‘Bad character lin 
application's buffer 


Not applicable 
Retry nine times 


Data service rate 
error 


Communication control 
block service rate 
error 


Replace illegal char- 
acter with delete 
characters 


Illegal character 0 (transmit) Lee! 
Sequence error, 7 (receive) 
Poll failure 


Nonexistent resource, = No retry possible 


or 
*"See Table 6-1. 
"See Table 8-4. 


Bus parity error, or 
Unrecoverable memory 
error 


Excessive checksum or 
parity error 


Retry nine times 
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Table 8-8. MLCP Error Condition Reported by 


VIP Line Protocol Handler 


VIP Posted Error 
Error Condition] Configuration |Return et eae er re 


No interrupt 
from MLCP 


P, C (except 
open) 


P, C (open 
only) 


NP, C 


NP, 


°VIP configuration codes are: 


Possible Recovery Action Comments 


Retry five times 


None 


P - polled; NP - not polled; C - control station 


>See Table 6-1. 


“See Table 8-4. 


Poll failure 


CCP/MLCP failure 


VIP lockup 


VIP inaccessible 
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PROCESSING NONPOLLED VIP ERRORS 


When the VIP does not send a Q-frame within 15 seconds after 
the data connection is made (i.e., DSR (data set ready) on), the 
line protocol handler posts the connect IORB with a return status 
of 6 (see Table 6-1) and with all I ST bits set to 0. 


When the VIP sends a message within 15 seconds after the 
data connection is made (i.e., DSR on), and the mesSage is 
erroneous (missed EOT character, parity error), the line protocol 
handler posts the connect IORB with a return Status of B and with 
all I ST bits set to 0. 


In either case, the application can reissue the connect 
request without first issuing a disconnect directive. 


When, after a successful connect, the application loses com- 
munication with the VIP and there are no outstanding requests on 
the VlLP queue, the application will not be notified until the VIP 
line protocol handler receives the next read or write request. 
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SECTION 9 


POLLED VIP EMULATOR (PVE) LINE PROTOCOL HANDLER 


The PVE line protocol handler allows a Level 6 System to be 
connected to a communications link that operates according to the 
polled VIP protocol. The line can be half or full duplex, may be 
dedicated or Switched, and operates at up to 9600 baud. 


The computer that controls the communications link is known 
as the control station (CS), which may be any Honeywell host 
system that supports the VIP protocol. 


GENERAL PVE OPERATION 


The PVE appears to the control station as a VIP terminal, 
and is the tributary station. Each PVE supports up to 32 tribu- 
tary stations per line, as designated at system building. 


To the control station, each PVE tributary station is known 
externally by a poll address, and internally to a Level 6 control 
Station, by a logical resource number (LRN). There is a one-to- 
one relationship between the poll address and the LRN. 


An application program in a Level 6 system communicates with 
the control station by issuing read and write requests to the 
appropriate LRN. Similarly, the control station sends and 
receives as though it is communicating with a polled VIP that has 
the appropriate poll address. 


Figure 9-1 illustrates a typical PVE configuration. 
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LINK 


=O Onn a 
POLLED 
VIP’s <j L6 


CS = CONTROL STATION a 
TS = TRIBUTARY STATION 


M = MODEM | nex fn fd fs fs 


MIU = MULTIPLE INTERFACE UNIT 


Figure 9-l. Typical PVE Configuration 


When the PVE receives a select request with the LRN- 
associated poll address, it forwards the message to the control 
station to satisfy the application's read request. When the PVE 
receives a poll request for the LRN-associated poll address, it 
forwards the message to the control station to satisfy the 
application's write request. Thus the application provides the 
equivalent of the screen and keyboard, with read and write 
requests, respectively. 


The PVE line protocol handler supports only the screen and 
keyboard features of the VIP. 


USING THE PVE LINE PROTOCOL HANDLER 
PVE-Specific IORB Values 
The PVE-specific IORB item I CT2, device-specific word 


I DVS, and software status word I ST are shown in Tables 9-1, 


9-2, and 9-3, respectively. Section 6 describes the general form 
of the IORB. 


9-2 CBO3 


Cain 


Ate ; 


Table 9-1l. Function Codes in I CT2 in IORB 


Function 
Code Definition 
Pak eS a en | 
Wait online| Used by the line protocol handler 
3 to complete the description of 
Write the requested I/O function 


Read 
Connect 


Disconnect 


Table 9-2. PVE Device-Specific Word I_DVS in the IORB 


Bit Bit 
Number |Setting Meaning of Bit Setting 
a 
| 


For connect call only (function code A) 


Do not use Auto Call Unit 


Use Auto Call Unit 


1 
2 
a 
eee 

 cosmvenssdeidannsteenmamenseesssyemnapinons 
 enieeepaatendanereceticscecsaptessercescsonene! 


Does not support VIP function codes. 


Supports VIP function codes. 


Include received DEL characters in 
buffer. 


A 


Strip received DEL characters. 


—60 
1 
0 
1 
0 
1 
a 
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Table 9-2 


ot 


PVE Device-Specific Word I_DVS in the IORB 


Bit Bit _ 
Number Setting Meaning of Bit peadgat 


LPH response to application when 
LPH receives data but no read IORB 
available 


Send NAK. 

Send ACK. VIP — 
Status 

Return busy status. Codes 


Send NAK (same as 00). 


Abort (dequeue) all IORB'S on 
request queue. 


Process all outstanding requests on 
request queue. 


Hang up phone after disconnect. 


Do not hang up phone after 
disconnect. , 
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Table 9-3. PVE Software Status Word I ST in the IORB 


eee 
0 


Meaning When Bit Set to l 


N/A 
N/A 
Data service rate error 


N/A 


Communications control block (CCB) 


error 
N/A 
Long record 


0 ETX character received 
1 ETB character received 


NAK limit reached 

Excessive checksum/parity errors 
Nonzero residual range 
Phone hang-up 

N/A 

N/A 


N/A 


Fatal error: bus parity or memory error 


Although nonexistent resource, bus parity, and 
uncorrectable memory errors are combined in bit 
F, each occurrence is noted separately in the 

resource control table (RCT). 


VIP Protocol Message Structure for PVE 


PVE. 


Figure 9-2 shows two VIP protocol message structures for 


See Figure C-l. 
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TYPE 1: 


MESSAGE 
HEADER 


TERMINAL POLL ADDRESS 
ADR TERMINAL SELECTION ADDRESS 
STA _ DISPLAY ADDRESS 


NUMBER OF CODES MAY VARY FROM CPU TO CPU. 
THE NUMBER OF CODES MUST BE ZERO FOR A POLL 
OR SELECT MESSAGE. A CODE OF 26g MUST NOT BE 
INCLUDED IN THE LP CALCULATION. ONLY THE 

FIRST TWO FUNCTION CODES ARE RECOGNIZED BY 
THE TERMINAL. 


(TEXT) 
ETX ————_{ way BE ETB CHARACTER 
LP 


LONGITUDINAL PARITY 
CHARACTER; INCLUDES ADR 
THROUGH ETX, LESS SYN. 


TYPE 2: (QUIESCENT MESSAGE) 


SYN SYN 
SYN SYN 
SYN OR SYN 
SYN (OPTIONAL) EOT 
EOT 


Figure 9-2. VIP Protocol Message Structure for PVE 
Control and Characteristics of PVE Input 


PVE INPUT MESSAGE HEADER 


The PVE line protocol handler strips the message header, 
between the SOH and STX control characters, and does not include 
it in the application's buffer. 


PVE HARDWARE FUNCTION CODES 


PVE hardware function codes are listed in the ce 
hardware device manuals. 


These codes provide a special message-labeling capability to 
be used by the application. 
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The application can include two function codes in the mes- 
Sage header of each text message by setting to 1 the bit 8 of the 
ITORB's device-specific word I DVS (See Table 9-2) at connect 
time. The line protocol handler then inserts the two user- 
specified hardware function codes at read time into the IORB'sS 
item I FCS (see Figure 6-1 and Table 6-2). 


PVE INPUT DATA 


The line protocol handler places into the application's buf- 
fer all data between the STX and ETX control characters. The 
data is inserted into the buffer in 7-bit ASCII, with the most 
Significant bit always zero. The LPH strips the ETX and LRC 
(longitudinal redundancy check character, see Appendix A) from 
the data and does not include them in the buffer. 


It also strips DEL characters when the application, at con- 
nect time, sets to 1 the A-bit of the device-specific word I DVS 
(Table 9-2). 


By setting the E- and F-bits of I DVS as shown in Table 9-2, 
the application can control the response that the line protocol 
handler sends when it receives data from the application, but no 
read IORB is available. 


Control and Characteristics of PVE Output 


PVE OUTPUT MESSAGE HEADER 


The PVE line protocol handler normally supplies the output 
header, between the. SOH and STX control characters. The applica- 
cation may specify hardware function codes (l, 2) as described 
above under "PVE Hardware Function Codes." At write time, when 
specified, the codes are extracted from the I_ FCS item of the 
IORB. When the codes are not specified, (bit 8 of I DVS set to 0 
at connect time), the line protocol handler will supply two 
Spaces, instead of the codes, into I FCS. 


PVE TERMINAL ADDRESS (ADR) AND MESSAGE STATUS (STA) 

The PVE line protocol handler supplies an ADR (terminal 
address) of X'60' (keyboard/screen) and an STA (message status) 
of NUL to the application. : 

PVE OUTPUT DATA 


The application's output data must be 7-bit ASCII. The most 
Significant bit is used by the line protocol handler during 
transmission of odd parity. 


Output data must not include the ASCII control characters 
SOH, STX, ETB, ETX, EOT, or SYN. 
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The line protocol handler supplies output ETX control char- ae 
acters and longitudinal redundancy check characters (LRCs) 
(described in Appendix A). 
PVE LINE PROTOCOL HANDLER TIME-OUT INTERVALS 
Table 9-4 lists the time-out intervals used by the line 
protocol handler for the connect, read, and write functions. The 
line protocol handler will attempt or reattempt the functions 
until the indicated time-out period has elapsed. 
In addition to the interval in the table, there is alSo a 
gross time-out of one minute, which expires when the control sta- 
tion ceases to poll or select any tributary station. 
Table 9-4. PVE Time-Out Intervals 
Time-Out Interval 
SEL A STEER ISIE) TSIEN TLIO a OR AE ET ET AR AE AOE, | 
Connect Five minutes 
Read Indefinite 
Write Indefinite 
ERROR REPORTING BY PVE LINE PROTOCOL HANDLER 7 me 
Table 9-5 lists the errors reported by the PVE line protocol 
handler. It also lists corresponding return status error codes 
(see Table 6-1) and corresponding bits in the software status 
word I ST (see Table 9-3). 
NU 
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Table 9-5. Errors Reported by PVE Line Protocol Handler 


: Posted Error oe 
Error Condition Return Status | Bit Comments 


No interrupt from MLCP 


NAK limit reached 


Purged due to immediate 
close 


Station disabled 


Fatal error interrupt 
level 


Data service rate error 


Communication control 
block service rate error 


Long record 

Phone hang-up 
Nonexistent resource, or 
BuS parity error, or 


Unrecoverable memory 
error 


“Poll failure or 
CCP/MLCP failure 


Write failure 


(send) Not fatal 
(receive) 


Not fatal 
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SECTION 10 


BSC 2780/3780 LINE PROTOCOL HANDLER 


The BSC (binary synchronous transmission) 2780/3780 line 
protocol handler (LPH) Supports BSC 2780 and BSC 3780 point-to- 
point, nontransparent or tranSparent EBCDIC, or nontransparent — 
ASCII transmission between a Level 6 system and another host sy S— 
tem (subject to certain restrictions). 


The 3780 protocol is very similar to the standard 2780 
protocol and unless specifically stated otherwise, the rest of 


this section and the term BSC pertain to both. 
GENERAL BSC LINE PROTOCOL HANDLER OPERATION 


When a station (device or computer) at either end of a com- 
munication line has a message to send, it requests use of the 
line by sending a ENQ bid message. (See Appendix E for defini- 
tion of ENQ and other control characters.) The receiving station 
must respond with an ACK/0O sequence before the sending station 
can transmit a data message. | 


BSC Transmit and Receive Operations 


A station that has control of the line, i.e., the right to 
transmit, is known as the master (primary)' station. The station 
that relinquishes control, i.e., will receive, is the slave 
(secondary) station. 


When the first data message from the master station is suc- 
cessfully received, the slave station responds with an ACK/1 
sequence. Acknowledgments for subsequent remaining messages 
alternate between ACK/O and ACK/1. The master/slave status for 
each respective station remains in effect until the master sta- 
tion gives up control by sending an EOT (end-of-transmission) 
character (which is not acknowledged by the slave station). 


Primary and secondary are arguments of the CLM BSC directive 
used when the system is being built. 
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When a bidding station does not receive an ACK/O response 
within a specified interval (time-out period), it sends another 
ENQ message. At the Same time, or at nearly the same time, the 
other station may be sending an ENQ message, bidding for the 
line. Thus both stations may be bidding with neither receiving 
an ACK response. This is known as line contention. Line conten- 
tion can be avoided by designating one station as the primary and 
and the other as secondary when the system is built. Then when 
the designated primary station receives an ENQ response to its 
bid message, it retransmits the ENQ message to the secondary sta- 
tion, which in turn ignores its own bid request and responds to 
the primary station with an ACK or NAK. 


The BSC line protocol handler allows a receiving station to 


reply to a data message with an RVI (reverse interrupt) message 
if it has an urgent requirement to transmit data. 


llustrates bids and other interactions between 
yw ua ust VV 


ise 


BSC Data Transmission Modes 


BSC operates in either basic data transmission mode or in 
advanced data transmission mode, according to whether a control 
byte 1S included in the data being transmitted. (See "BSC 
Control Byte (Receive)" and "BSC Control Byte (Send)" later in 
this section.) 


BSC BASIC DATA TRANSMISSION MODE 


In basic data transmission mode, there is no control byte 


included in the data being transmitted along the communications 
line. 


BSC ADVANCED DATA TRANSMISSION MODE 


In advanced data transmission mode, the application includes 
a control byte (that is not part of the data). The control byte 
indirectly controls the operation of the line protocol handler 
(e.g., sending an ETB or ETX), or conveys information about a 
data transfer (e.g., whether transparent text was received). 
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PRIMARY STATION A SECONDARY STATION B 


BIDS ENO (BID) 
ACKO ACCEPTS BID 
DATA 
ACK1 


++ 


MASTER DATA 


ACKO 
EOT (RELEASE) 


SLAVE 


RELEASE 
ENQ (BID) 


-+—_——_——.——_ BIDS FOR PRIMARY 
ACCEPTS BID ____ACKO 
DATA 


MASTER 
SLAVE ACK1 


TIME OUT ee eae 1 
BIDS AGAIN 


{ 
ACKO ACCEPTS BID 
-__J WOULD HAVE TIMED-OUT HERE 


Figure 10-1. Example of BSC Communication 
BSC 2780 AND BSC 3780 DIFFERENCES 


The 3780 protocol differs from the 2780 protocol in that the 
3780 protocol has a set of extensions that provide: 


o The ability to receive a conversational reply. 


o The ability to receive two records and to transmit a 
Single record, when the two-buffer option is selected at 
connect time. 


o The ability to receive and transmit selected BSC control 
Characters in nontransparent mode. 


BSC 2780/3780 FEATURES 


The following discussions in this subsection include refer- 
ences to BSC-Specific fields in the input/output request block 
IORB (see Table 6-2) and to control bytes, and precede their 
descriptions. See Tables 10-2 and 10-3 later in this section for 
descriptions of the device-specific word I DVS and software 
status word I ST, respectively. Control bytes are described 
under "Control Byte (Receive)" and "Control Byte (Transmit) ." 


BSC Two-Buffer Feature 


With the two-buffer feature, the use of the second buffer 


reduces line turnaround time, i.e., two records can be transmit- 
ted with only one acknowledgment. However, there are these 
disadvantages: 
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o When a line (parity) error occurs, both records must be 
retransmitted. 


o One transmission requires two writes be issued, which are 
not posted until an acknowledgment is received. 


o Four buffers are necessary to operate the line 
efficiently. 


Figure 10-2 shows record transmissions with and without the 
two-buffer feature. 


ITB BCC SYN SYN STX ETB BCC 


CO  ———— 
WITH TWO-BUFFER FEATURE 


ETB BCC 


ACKO —————_——_—_________—_—_-_—- 


ETB BCC 


PACK 1 eg 


~ WITHOUT TWO-BUFFER FEATURE 


Figure 10-2. BSC Two-Buffer Feature in Record Transmission 


Before selecting the two-buffer feature, compare the advan- 
tage of better line utilization against the disadvantages of a 
more complex program and increased buffer usage, and consider the 
following: 


1. In BSC 2780 with the two-buffer option, two records can 
be received or transmitted (using an ITB (intermediate 
text block) sequence). : 


2. In BSC 3780, with the two-buffer option two records can 
be received, uSing an ITB sequence, and Single records 
can be transmitted. This implies that an application 
uSing BSC 3780 must be able to receive up to two records 
at any one time, but can only initiate single-record 
transmission. | | 
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ASE, 


The two-buffer feature cannot be used with synchronous 
reads, because the intermediate files being received may 
be terminated by an ETX record. If the ETX record is 
the first of the two records being read, the second read 
(synchronous) would not be posted to the system. 


For example: | 


READ (asynchronous) 
- process | 
Assumes always two records 


READ (synchronous) per transmission. 


- process 


The following sequence is better: 


READ (asynchronous) 


READ (asynchronous) 
WAIT (1) 


- process 


READ (asynchronous) 
WAIT (2) 


» process 


BSC Temporary Text Delay (TTD) Feature 


| The following describes the sequence of the temporary text 
delay (TTD) feature. 


Ie 


When a master station receives an ACK, and no output 
request block (IORBS) are queued, that station waits two 
seconds for one IORB (or two IORBsS when there are two 
buffers) to be queued. 


The master station then sends the temporary text delay 
(TTD) control character sequence (STX, ENQ) to the slave 
station. 


When the slave Station responds with a NAK, the master 
Station checks whether the application has queued the 
appropriate write requests. If the write requests are 
not queued, the master station continues the TTD 
sequence until the application issues the necessary 
write requests. 
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4. If the EOT or ETX bit (A-bit or D-bit) in the I DVS word 
of the IORB is set (Table 10-2), one write request will 
effect transmission. 


Figure 10-3 is an example of the EEmpOrSrY text display 
sequence. 


MASTER SLAVE 


MESSAGE) 
a ACK/0 

MESSAGE) enn nnn ssn 
nnn ACK / | 

TSX, NO 
—_—————— eee NAK 


cmmemmccccmeeene — f\ /\ (C 
MESSAGE 3- een nnn nn 


fenton ACK /() 


Figure 10-3. BSC Temporary Text Delay (TTD) Sequence Example 
BSC Wait Before Acknowledge (WACK) Feature 


A BSC slave station will send ACK/0O and ACK/1 responses to 
messages satisfactorily received, provided there is at least one 
outstanding read request (two with the two-buffer feature), in 
addition to the request being processed. 


1. When no read request is queued, the slave station posts 
- the current read, waits two seconds for read requests to 
be queued, then sends a WACK reSponse (DLE; DLE,), indi- 
cating to the master station that the last message was 
received, but the slave station cannot accept more data. 


2. The master station waits (time-out), then sends an ENQ 
“message. 


3. If a read request was queued during the time-out, the 
Slave station responds with an ACK, and the master sta- 
tion can send its next data message. 


4. If no read request was queued during the time-out, the 
Slave station waits another two seconds, and when neces- 
Sary sends another WACK sequence. 
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Figure 10-4 is 


(WACK) 


sequence. 


MASTER . 
MESSAGE 1 


MESSAGE 2 


MESSAGE 3 


TIMEOUT 


ENQ 


MESSAGE 4 


Figure 10-4. 


an example of the wait before acknowledge 


SLAVE 


Sequence Example 


BSC Reverse Interrupt (RVI) Feature 


When a Slave station iS processing read requests, and must 
unexpectedly transmit an urgent message, that station must issue 


a reverse interrupt 


On receiving an RVI character, the master station should 
empty its buffers and give up control of the line. 
master station does not have to acknowledge the RVI by giving up 


control. 


The application program can request the BSC line protocol 
handler to send an RVI character, by either of the following 


methods: 


ie 


Use the control byte. 


Use the device-specific word I DVS of the IORB. 
application issuing read requests issues a transmit 
request with the B-bit of I DVS set to 1 and with the 
urgent message in the application's buffer. 


(RVI) message, which informs the master sta- 
tion that the slave station is requesting control of the line. 
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BSC Wait Before Acknowledge (WACK) 


The application issuing read 
requests issues a transmit request with bit 5 of the 
control byte set to 1 (see Figure 10-10), and with the 
urgent message in the application's buffer. 


The application issuing write requests can detect an RVI 
character by any of these methods: 


Mees 


2e 


Test bit 3 of the control byte after a successful 
write request is posted. A bit setting of 1 indicates 
that the RVI for that IORB was received. | 


Test bit 3 of the IORB's software status word I ST. A 
bit setting of 1 indicates the RVI was received. 


Figure 10-5 is an example of a reverse interrupt (RVI) 


sequence. 


MASTER SLAVE 


MESSAGE 11. ————$—$—$————————————— 
——$$ $$ Ack 0 
MESSAGE 2. ———_—_—$—$—$—$_$ _— $= 
$$$ Ack 
MESSAGE 33©_ —__$—=—$_$_$_$_ $$ 
$$ $$$ $$ VI 
MESSAGE 4. ——=—__—_—_ a 
a a ACK 
EOT Se 
————— es ENO 
ACK/O —_—_—_—_—_—_—_———_— enn eee 
: URGENT MESSAGE 


(NOW MASTER) 


ACK/1 Se ee 


Figure 10-5. BSC Reverse Interrupt (RVI) Sequence Example 


BSC End of Transmission (EOT) Feature 


The appliation program, by any of the following methods (l, 


2, or 3), 


can cause the BSC line protocol handler to send an end- 


of-transmission (EOT) message: 


la. 


At connect time, specify use of the control byte by 
setting to 0 bit 4 of the IORB's device-specific word 
I DVS. | 


When bit 4 of the first byte of the application's buffer 
(control byte, specified at write time) is set to l, the 
BSC line protocol handler will send an EOT control char- 
acter after the data in the application's buffer is 
successfully transmitted. 
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Ao 
pews ty 


Me r 


ABB 


2a. When the control byte is not specified at connect time, 
set to 1 the A-bit of the IORB'sS device-specific word 
I DVS at write time. 


b. The BSC line protocol handler will send an EOT control 
character after the data in the application's buffer is 
successfully transmitted. 


3a. After successful completion of a write request, issue a 
disconnect with or without a queue abort, and no physi- 
cal disconnect. 


b. The maSter station will send an EOT character and give 
up itS master status. 


c. However, when another IORB is queued for write, that 
station will again request its master status. 


The application can detect receipt of an EOT control charac- 
ter in either of the following ways: 


1. If the control byte was specified at connect time, bit 4 
of the control byte, of the read request on which the 
EOT was received, will be set to l. 


2. If the control byte was aoe specified at connect time, 
bit 12 of the software status word I ST, of the request 
on which the EOT character was received, will be set to 
Pig 


With either method, the line protocol handler does not post 
any read requests that were queued before the EOT character was 
detected. To remove read requests from the queue, the applica- 
tion must issue a disconnect with a queue abort. The line proto- 
col handler always posts the IORB with a device unavailable (B) 
return status (Table 6-1). The BSC line may or may not be 
available for further use, depending on whether or not an EOT 
character was sent abnormally. 


BSC Line Protocol Handler Time-Out Interval 


On a read, the time-out interval in waiting for a line- 
request bid is 10 minutes. : 


For a read or write request, when no response is received, 
the time-out interval is 12 seconds. 


Once a station has successfully bid for a line, the time-out 


interval for subsequent reads (from the slave station) or writes 
(from the master station) is 12 seconds. 
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BSC Features Specific to 3780 
BSC 3780 CONVERSATIONAL REPLY FEATURE 


The conversational reply feature permits a 3780 application, 
after transmission of an entire message (whose last record is. 
denoted by an ETX rather than an ETB), to selectively receive a 
message from a host computer without a preliminary line bid 
sequence. 


The conversational reply sequence serves as the affirmative 
reply to the last message transmission block, and as a break or 
interrupt to later transmissions. The line protocol handler 
indicates to the application receipt of a conversational reply 
Sequence in bit 5 of the IORB software status word I ST, and/or 
in bit 2 of the control byte of the ETX write order. 


In the following example, a 3780 application attempts to 
transmit three 2-record messages to a remote host computer. The 
transmission sequence is interrupted by the receipt of a conver- 
Sational reply, which occurs after transmission of the second 
message. After the complete conversational reply (containing one 
Or more records) is received, transmission of the third message 
can resume, following completion of a successful line bid 
sequence. Figure 10-6 illustrates the example sequence. 


The application's use of the conversational reply feature 
requires that the application issue the requisite number of read 
orders (dependent on one- or two-buffer mode) before the trans- 
mission of a text block that terminates with an ETX sequence. If 
the application does not issue the required read(s), the last 
text block is not transmitted, and the line protocol handler will 
initiate a temporary text delay (TTD) sequence until the neces- 
Sary read orders are issued. If the application does not trans- 
mit an ETX sequence, it need not issue Supporting read order(s). 


BSC 3780 TWO-BUFFER FEATURE 


The discussion under "BSC Two-Buffer Feature" earlier in 
this section applies also to BSC 3780 operation. 


BSC 3780 TRANSMISSION/RECEIPT OF BSC CONTROL CHARACTERS 


In BSC 2780 nontransparent mode, detection of any BSC con- 
trol characters within a message would abort the transmission or 
reception of that message. 


In 3780 nontransparent mode, selected, noncritical BSC con- 
trol characters, i.e., STX, SOH, DLE, NAK, and EOT, can be suc- 
cessfully transmitted and received. 
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HOST SUPPORTING 
BSC 3780 APPLICATION BSC 3780 APPLICATIONS 


TRANSMISSION OF , 
FIRST MESSAGE STX...ETX 


ACKO 

STX...ETB 
TRANSMISSION OF Ee eR Se 
SECOND MESSAGE 

STX...ETX 

STX... ETB 


errr nee ene reesei TSS SSD 
“INTERRUPTING” 
CONVERSATIONAL REPLY 

TRANSMISSION OF 

REMAINDER OF THE 


ieee tin CONVERSATIONAL 


TRANSMISSION OF 


THIRD AND . STX...ETX 
ACKO 


Figure 10-6. Example of Conversational Reply in BSC 3780 
Transmission Sequence 
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USING THE BSC 2780/3780 LINE PROTOCOL HANDLER 
BSC-Specific IORB Values 


The BSC-specific IORB item I CT2, device-specific word 


I DVS, and software status word I ST, are shown and defined in 


Tables 10-1, 10-2, and 10-3, respectively. Section 6 has a 
general description of the IORB. 7 


Table 10-1. Function Codes in I CT2 Field in the IORB 


| 


Used by the line protocol handler 


Function 
Code Definition 


Wait online 
to complete the description of 
the requested I/O function. 


Disconnect 


Table 10-2. BSC Device-Specific Word I DVS in the IORB 


Bit Bit. | | 
Number |Setting Meaning of Bit Setting 


0 
1 Must be zero. 


| For connect call only (function code A) 


Do not use Auto Call Unit. 


Must be zero. 


Use Auto Call Unit. 
Must be zero. 


Use control byte. 


Do not use control byte. 
Must be Zero. 
Must be zero. 


Must be zero. 
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Table 10-2 (cont). BSC Device-Specific Word I DVS in the IORB 


Bit Bit 
Number | Setting Meaning of Bit Setting 


For connect call only (function code A) (cont) |. 


sites 
a 
Use Single buffer per transfer. 
| 2780: use two buffers per send/receive. 
3780: use two buffers per receive. 
BSC 2780 protocol. 
BSC 3780 protocol. | 


For write call only (function code 1) 


Do not send EOT after this transmission. 

Send EOT after enie epanemiasion: 

Do not send RVI if station in slave status. 
Send RVI if station in slave status. 

Send data in nontransparent mode. 

Send data in EBCDIC transparent mode. 

Send ITB or ETB characters following the data. 


Send ETX characters following the data. 


For disconnect call only (function code B) 
E Abort (dequeue) all IORBS on request queue. 
Process outstanding requests on request queue. 


F Disconnect line on completion. 


Do not disconnect line on completion. 


Specifying Use of BSC 2780 and/or 3780 to the System 


| The inclusion of BSC 2780 and/or 3780 in the system is done 
at system building. The application can select and use either 
2780 or 3780 according to the setting of bit 9 in the device- 
specific word I_DVS in the IORB (see Table 10-2). 
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Table 10-3. BSC Software Status Word I ST in the IORB | ee 


Meaning When Bit Set to l 
OESTRONE SFI ei NETCARE APN, ICAU IIE Rn EIST PON EIR SGT Cre DC Sn OSI EEC ERASER DD 
0 N/A | 
1 |N/A 


2 Data service rate error 
3 Lost line bid; RVI received 
4 Communications control block service error 


5 Conversational reply received (3780 only) 


6 |Long record 

7 Oo = EVR Sravscr ETS characters teceivead 
1 = ETX character received 

8 N/A 

9 N/A 

A Nonzero residual range 


B Phone hang-up 

C EOT character received 

D Transparent message received 
E NAK limit reached 


F Fatal error: bus parity or memory error 


Although nonexistent resource, bus. parity, and 
uncorrectable memory errors are combined in bit 
F, each occurrence is noted separately in the 
resource control table (RCT). See Figure C-l. 


Formats and Characteristics of BSC Input Data 


The formats and characteristics of BSC input data for both 
ASCII and EBCDIC are described and illustrated below. 


Figure 10-7 shows the format and contents of BSC input data 
received from another computer. | 
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(CONTROL BYTE) 


SOM (START OF MESSAGE) 
A ONE- OR TWO-CHARACTER SEQUENCE THAT !S STRIPPED BY 
THE BSC LPH. © 

CONTROL BYTE 
THE CONTROL BYTE, IF SPECIFIED, IS THE FIRST BYTE OF THE 
APPLICATION’S DATA. 

DATA ; 

INFORMATION STORED IN THE APPLICATION’S BUFFER AND 
SPECIFIED AT READ TIME. 

EOM (END OF MESSAGE) 
A ONE- OR TWO-CHARACTER SEQUENCE THAT !S STRIPPED BY 
JHE BSC LPH. 

BCC 


AN LRC CHARACTER OR CRC CHARACTER THAT IS INSERTED BY 
THE BSC LPH. 


Figure 10-7. BSC Input Data Format and Contents 


BSC CONTROL BYTE (RECEIVE) 


When bit 4 of the IORB's device-specific word I DVS is set 


to 0 at connect time (see Table 10-2), the BSC line protocol 


handler uses the first byte of the application's buffer as the 


control byte. Figure 10-8 shows the control byte's format and 


content. 


BITS 0 THROUGH 3 
NOT APPLICABLE; NOT EXAMINED 
BIT 4=0 _ | 
DATA STORED IN APPLICATION’S BUFFER 


BIT 4=1 
EOT RECEIVED; NO DATA STORED IN APPLICATION’S BUFFER 


BIT 5 
NOT APPLICABLE; NOT EXAMINED 


BIT 6=0 
DATA RECEIVED IN NONTRANSPARENT MODE 


BIT 6=1 
DATA RECEIVED IN TRANSPARENT MODE 


BIT 7=0 
ITB OR ETB RECEIVED 


BIT 7=1 
ETX RECEIVED 


Figure 10-8. Control Byte (Receive) 


for 


BSC Line Protocol Handler 
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ASCII INPUT FOR BSC 


ASCII input characteristics and format (Figure 10-7) are as 


follows: 


1. 


2« 


De 


SOM (Start-of-message) consists of the STX control char- 
acter only. 


The control byte (if specified at connect time) is 
Stored in the first byte of the applications' buffer, 
and indicates the end-of-message (EOM) sequence. 

When bit 7 is 0, it indicates detection of an ITB or ETB 
control character; when 1, it indicates detection of an 
ETX character. Note that bit 7 of both the control byte 
and of I ST are specified. 


Data must be 7-bit ASCII with odd parity. The BSC line 
protocol handler strips the parity bit and resets it to 
zero when it stores it in the appiication’s buffer. 


The EOM sequence, one of the three control chracters 
ITB, ETB, or ETX, is indicated by bit 7 of the IORB 
software status word I ST after a successful read is 
posted. See Table 10-3 for bit 7 indicators. 


The BCC (block check character) is described in 
Appendix A. 


EBCDIC INPUT FOR BSC 


EBCDIC input format and characteristics are as follows: 


deg 


2% 


SOM (start-of-message) consists of the STX control char- 
acter only. 


The control byte (if specified at connect time) is 
stored in the first byte of the application's buffer, 
and indicates the end-of-message (EOM) sequence, as 
follows: 


1 End of transmission (EOT) detected. 


Bit 4 = 
Bit 7 = 0 ITB or ETB character detected. 
Bit 7 = 1 ETX character detected. 


Data must be 8-bit EBCDIC; it will not have any BSC con- 
trol characters. 


The EOM sequence, one of the control characters ITB, 
ETB, or ETX, is indicated by bit 7 of the IORB software 
status word I ST after a successful read is posted. See 
Table 10-3 for bit 7 indicators. 
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5. The BCC (block check character) is described in 
Appendix A. | 


TRANSPARENT EBCDIC INPUT FOR BSC 


Transparent EBCDIC input format and characteristics are as 
follows: 


1. SOM (Start-of-message) consists of the two-character 
sequence DLE, STX. 


2. The control byte, if specified at connect time, is 
stored in the first byte of the application's buffer, 
and indicates the EOM (end-of-message) sequence accord- 
ing to the bit 7 setting (Figure 10-8). 


3. Data may be any EBCDIC character, including BSC control 
characters. | 


4. EOM (end-of-message) sequence may be one of the follow- 
ing, indicated by bit settings of the IORB software 
status word I ST, after a successful read has been 


posted: 
I ST Bits 
D we Resulting EOM Sequence 
1 0 DLE, ITB 
1 0 DLE, ETB 
1 1 DLE, ETX 


5. The block check character (BCC) is described in 
Appendix A. 


Formats and Characteristics of BSC Output Data 


Formats and characteristics of BSC output data (both ASCII 
and EBCDIC) are described and illustrated below. 


Figure 10-9 shows the format and content of BSC data trans- 
mitted to another computer. 
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(CONTROL BYTE) 


SOM 


A ONE- OR TWO-CHARACTER SEQUENCE THAT IS INSERTED IN FRONT 
OF THE DATA BY THE BSC LPH. 


CONTROL BYTE 


THE CONTROL BYTE, IF SPECIFIED, IS STORED IN THE FIRST BYTE 
OF THE APPLICATION’S BUFFER. 


EOQM 


A ONE- OR TWO-CHARACTER SEQUENCE THAT IS INSERTED BY THE 
BSC LPH. 


BCC 


AN LRC CHARACTER OR CRC CHARACTER THAT IS INSERTED BY 
THE BSC LPH. : 


DATA 


INFORMATION THAT IS TRANSMITTED FROM THE APPLICATION’S 
BUFFER BY THE BSC LPH. 


Fiqure 10-9. Format and Conte 


~ —2 


nf of BSC Out 


— 


BSC CONTROL BYTE (SEND) 


When bit 4 of the IORB's device-specific word I DVS is set 
to 0 at connect time (see Table 10-2), the BSC line control 
handler uses the first byte of the application's buffer as the 
control byte. Figure 10-10 shows the format and content of the 
BSC line protocol handler's control byte for sending data. 


efi fe[sfetefete 


BITS O, 1 
NOT APPLICABLE, NOT USED 
BIT 2=1 
CONVERSATIONAL REPLY RECEIVED 
BIT 3=1 
| RVI RECEIVED (RETURN STATUS ONLY) 
BIT 4=1 
SEND THE DATA THAT IS IN YOUR BUFFER AND, 
AFTER !T HAS BEEN ACKNOWLEDGED, SEND EOT 
BIT 5=1 
SEND AN RVI RESPONSE ON THE NEXT ACKNOWLEDGMENT 
OF A READ 
BIT 6=0 
SEND NONTRANSPARENT EBCDIC 
BIT 6=1 
SEND TRANSPARENT EBCDIC OR ASCII 
BIT 7=0 
SEND ITB OR ETB 
BIT 7=1 | 
SEND ETX 


Figure 10-10. Control Byte (Send) for BSC Line : 
Protocol Handler 
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BSC ASCII OUTPUT 


ASCII output characteristics and format are as follows: 


Le 


2 


Se 


SOM (Start-of-message) consists of only the STX 
character. 


The control byte, when specified, is assumed to be the 
first byte of the application's buffer, and indicates 
the EOM (end-of-message) sequence, which is either ITB, 
ETB, or ETX, designated as follows: 


a. Bit 6 must be O. 


b. Bit 7 = 0. Send ITB or ETB. ITB is sent when the 
record is odd numbered (1, 3, 5, etc.) and the two- 
buffer feature is used. 


Bit 7 = 1. Send ETX. 


If the control byte is not specified, the EOM sequence 
is defined by I_ DVS as described in 4 below. 


Data must be 7-bit ASCII; it cannot have any BSC control 
characters. 


EOM, which is either ITB, ETB, or ETX, can be indicated 
by the control byte (see 2 above) or by the C- and D- 
bits of the IORB device-specific word I DVS (Table 10-2) 
as follows: | 


a. C-bit must be zero. 

b. D-bit = 0. Send ITB or ETB. ITB iS Sent when the 
record is odd-numbered (1, 3, 5, etc.) and the two- 
buffer feature is used. 


BCC (block check character) is described in Appendix A. 


BSC EBCDIC OUTPUT 


EBCDIC output characteristics and format are as follows: 


1. 


2 


SOM (start-of-message) consists of only the STX 
character. 


The control byte, when specified, is assumed to be the 
first byte of the application's buffer, and indicates 
the EOM (end-of-message) sequence, which is either ITB, 
ETB, or ETX, designated as follows: : 
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oe 


a. Bit 6 must be OQ. 


b. Bit 7 = 0. Send ITB or ETB. ITB is sent when the 
record is odd-numbered (1, 3, 5, etc.) and the two- 
buffer feature is used. 


Bit d= Aes Send ETX. 


If the control byte is not specified, the EOM 


sequence is defined by I DVS as described in 4 
below. : 


Data may be 8-bit EBCDIC; it cannot have any BSC control 
characters. 


EOM (end-of-message), which is either ITB, ETB, or ETX, 
can be indicated by the control byte (see 2 above) or by 
the C- and D-bits of the IORB device-specifid word I DVS 
(Yable 10-2) as follows: 

a. C-bit must be zero. 


b. D-bit = 0. Send ITB or ETB. ITB is sent when the 
record is odd-numbered (1, 3, 5, etc.) and the two- 
buffer feature is used. | 
D-bit = 1. Send ETX. 


BCC (block check character) is described in Appendix A. 


BSC TRANSPARENT EBCDIC OUTPUT 


Transparent EBCDIC output characteristics and format are as 


follows: 


1. 


2 


SOM (start-of-message) consists of the two-character | 
sequence DLE, STX. 


The control byte, when specified, is assumed to be the 
First byte of the application's buffer, and indicates 
the EOM (end-of-message) sequence, which is either DLE 
ITB; DLE ETB; or DLE ETX, designated as follows: 


a. Bit 6 must be O. 

b. Bit 7 = 0. Send DLE ITB or DLE ETB. DLE ITB is 
sent when the record is odd-numbered (1, 3, 5, etc.) 
and the two-buffer feature is used. 


Bit 7 = 1. Send DLE ETX. 
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If the control byte is not specified, the EOM sequence 
is defined by I DVS as described in 4 below. 


Data may be any EBCDIC character, including any BSC con- 
trol characters. 3 


EOM, which can be either DLE ITB; DLE ETB; or DLE ETX, 
can be indicated by the control byte (See 2 above) or by 
bit 4 and bit D of the IORB device-specific word I DVS 
(Table 10-2) as follows: 

a. Bit 4 must be l. 

b. D-bit = 0. Send DLE ITB or DLE ETB. DLE ITB is 


sent when the record is odd-numbered (1, 3, 5, etc.) 
and the two-buffer feature is used. 


D-bit = 1. Send DLE ETX. 


BCC (block check character) is described in Appendix A. 
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APPENDIX A 


COMMUNICATIONS SUBSYSTEM 


Communications software, as discussed in this manual, is a 


functional package referred to as the communications subsystem, 
and which comprises: 


0000 


Communications supervisor 

Line protocol handlers (LPHs) 

Multiline communications processor (MLCP) 
Multiline communications processor driver 


COMMUNICATIONS SUPERVISOR 


The communications Supervisor is the physical I/O interface 
between a communications application program and the device/files 


it uses. 


It provides the following services, similar to those 


provided by the Monitor, to an application: 


O 


oO 


Validates and queues, ona first-in/first-out basis, an 
application's requests for services, then activates the 
appropriate line protocol handler. 


Dequeues requests for services, and through system soft- 
ware, interacts with the application when the requested 
I/O service is completed or an unexpected event occurs. 


Services time-outs for the line protocol handlers. 


Controls modems in detecting phone connects and 
disconnects. 


Disconnects phones when requested by the application. 


LINE PROTOCOL HANDLERS (LPHS) 


The line protocol handlers transfer data between a communi- 
cations device and the application that uses it. 
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The communications subsystem and its line protocol handlers 
do the following: 


oO 


When the system is bootstrapped: 


- Validate specifications for device types by reading 
the device's identification Sequence 


- Initialize the device by sending to it the priority 
level at which it is to operate 


Validate the appr ealton: s input/output request block 
(IORB) fields 


Convert user-supplied functions into device-specific 
instructions, initiating the I/O operation 


Modify channel numbers to even or odd values, according 
to whether the function iS input or output 


Set a timer in order to detect a device fault 


Detect and process ATTENTION signals 


Read return status indicators from a device to ascertain 
result of an I/O operation | 


Process error recovery, when possible 
Process unsolicited interrupts 
Build the return status word indicating logical result of 


the I/O request, and through the Monitor, passing that 
value to the application program 


Pass a value indicating the logical conclusion of the I/O 
request, through the Monitor, to the application program. 
(Table 6-1 lists the return status codes). 


Report the following errors and statuses: 


- Convert hardware return status into the standard soft- 
ware.statusS and insert it into the software status 
word I ST of the application's IORB (see Table 6-3). 


- Place the reSidual range value (see Table 6-2) into 
the I_RSR entry of the IORB. 


A-2 —— CBO03 


y ae 


MULTILINE COMMUNICATIONS PROCESSOR (MLCP) 


The MLCP includes a channel control program (CCP) that is 
associated with each line protocol handler (See Figure A-1l). 


Through the appropriate hardware device-pac, the channel 
control program controls transmission of data over communication 
lines. Its functions are: 


o Process characters by storing them in, then extracting 
them from, a buffer 


o Insert and delete (or Strip) headers and trailers 


o Insert and delete control characters preceding or follow- 
ing a message to or from a remote terminal or host 
computer. 


The MLCP Programmer's Reference Manual describes the MLCP 
and related programming information. | 


MULTILINE COMMUNICATIONS PROCESSOR DRIVER 


The MLCP driver receives MLCP orders from the line protocol 
handler and activates the appropriate channel control program 
(see above and Figure A-1) to process the orders. The driver 
also: 


o Processes a line protocol handler's requests for control 
functions or for data 


o Services interrupts from the MLCP and passes them to the 
line protocol handler 


MODEM SUPPORT 


For asynchronous devices, the communications subsystem sup- 


ports the direct~connect feature, and provides the following 
modem Support: 


o Bell System Data Sets, Types 103A, 113F, or 202 
o Honeywell modem bypass 
o Any user-defined (at system building) modem type 


For synchronous communications, the communications subsystem 
Supports the direct-connect feature, and provides the following 
modem support: 


O Bell System Data Sets, Types 201A, 201B, 201C, 203, or 
208A 


Oo Honeywell modem bypass 
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o User-defined (at system building) modem types 
AUTO CALL UNIT 

When included in the system (at system building) an Auto 
Call Unit (autodial feature) performs the following to initiate a 


line connection with a remote device: 


1. The system attempts to dial a line, using a list of 


telephone numbers supplied at system building, the first 


entry on the list being zero. The first number to be 
dialed can then be specified with a set dial (S$SDL) 
macro call or with the set ACU telephone number (SDL) - 
command. If the first number on the list is not speci- 
fied (by the macro call or command), the system skips to 
the next number on the list. 


2. Dials each number on the list three times at 40-second 
intervals until the list is exhausted or a connection 
made, whichever comes first. 

3. Checks that a connection to a modem is made. 


4. Passes control to the application. 


The Auto Call Unit supports Data Auxiliary Set Automatic 
Calling Units 801A and 801C. 


Two data set options are required to use the Auto Call Unit: 


o The option that terminates the call, through the data 
set, after the DSS (data set Status change) goes on. 


o The option that stops the ACR timer when the DSS goes on. 
COMMUNICATIONS SUBSYSTEM OPERATION EXAMPLE 


The following example, and Figure A-1, broadly indicate the 
interaction of the communications subsystem's components in the 
processing of a connect, write and then disconnect request. The 
operations described apply to either the file system or physical 
I/O interface, without reference to a specific device or line 
protocol. 
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The communications Supervisor takes the application's 
connect request through the file system or physical I/0 
interface, then passes it to the phone monitor within 


the multiline communications processor. 


The phone monitor makes a line connection to the device. 


The appropriate line peoroee:: handler processes the 
logical connection. 


The communications supervisor passes the application's 
Subsequent write request to the line protocol handler, 
which translates the request into MLCP driver orders. 


The line protocol handler calls the MLCP driver, which 
issues the orders to the MLCP. 


The channel control program in the MLCP processes the 
write order, transmitting the data to the device, during 
which the line protocol handler suspends itself. 


When the MLCP senses completion of the data transfer, 
the channel control program returns an interrupt that is 


initially processed by the communications supervisor and 
the MLCP driver. 


The MLCP driver reactivates the line protocol handler 
(at the interrupt level) to minimally process the 
interrrupt. | 


When processing 1s completed, control passes to the 
MLCP driver. 


If additional processing is necessary, the line 
protocol handler can schedule itself, on a noninterrupt 
basis, to do postinterrupt processing of the interrupt. 


The application's disconnect request iS processed the 
same aS a connect request: 


a. As requested by the communications processor, the 
channel control program disconnects the physical 
connection. 


b. The line protocol handler does the necessary logical 
disconnect procesSing. 
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COMMUNICATIONS SUBSYSTEM ERROR AND CORRECTION PROCEDURES 


GCOS uses the following procedures including parity check- 
ing, block checking, and time-out, to detect errors occurring 
over communication lines. 


Parity Error Check 


The system sends a parity (check) bit with each transmitted 
character. The parity bit, plus the number of character bits set 
to 1, will always be an odd- or even-numbered total for every 
character, according to whether transmission is synchronous or 
asynchronous. The standard for synchronous transmission is odd 
parity (total is an odd number); for asynchronous transmission it 
1S even parity (total is an even number). 


Block Error Check 


GCOS uses two kinds of biock error checking, the longitudi- 
nal redundancy check (LRC) and the cyclic redundancy check (CRC). 
Their check characters are known as block check characters (BCC), 
and the checking calculation result is a block checksum. 


LONGITUDINAL REDUNDANCY CHECK (LRC) 


The LRC is a form of parity check that is applied to the 
entire message. The system appends an LRC character, which is an 
exclusive OR of the message characters, to every message. 


The VIP and PVE line protocol handlers use the LRC method. 
CYCLIC REDUNDANCY CHECK (CRC) 


The CRC method is block oriented. The system transmits data 
without appending a parity bit on every character. The system 
computes the CRC character(s) with special algorithms applied to 
the data to be checked, then appends these characters to the 
message. 


Only the BSC line protocol handler uses the CRC method. 
BSC BLOCK CHECK CHARACTER (BCC) 


In ASCII transmission, the 8-bit block check character BCC 
is the result of an exclusive OR operation on all bits received, 
beginning with the first character following the STX, and ending 
with the ITB, ETB, or ETX control character. It is based on the 
polynomial x® +1. | 


In EBCDIC transmission the block check character (BCC) is 16 


bits, and is. calculated 6 the system with the checking poly- 
nomial 1. + x2 + x® 4 x'6 
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Time-Out Check 


After sending a message, the transmitting device/computer 
waits for an acknowledgment from the receiving device. When 


there is no acknowledgment after a specific interval, the sender 
retransmits the message. 


When there is no acknowledgment after a specified number of 


transmissions, the sender takes whatever action is programmed 
into the system. | 


Some procedures provide that the receiving device, on 
receipt of erroneous data, request retransmission from the 
sender, using the ACK/NAK response method. (See Appendix E for 
ACK/NAK definitions.) In this procedure, the sending device 
waits for an ACK or NAK response (or elapse of the time-out 
interval) before continuing the communication. 
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APPENDIX B 


CHANGING TERMINAL'S FILE CHARACTERISTICS 


Before an application is executed, the user can change the 
File characteristics of a terminal, e.g., line length or record 
Size, detabbing, device type (input, output, etc.), with the sys- 
tem command STTY (set terminal characteristics) or with the SSTTY 
macro call. | 


This permits the user to modify those terminal character- 
istics established at system building. 


Table B-1l shows examples of possible values for the device- 
specific word and file-indicator word arguments of the STTY com- 
mand and the SSTTY macro call (described in the Commands and 
System Service Macro Calls manuals, respectively). 


The table indicates the following: 


Column 1 - Device/file operational mode; for BSC, whether 
advanced or basic data transmission mode. 


Column 2 - Input/foutput operations specified by the corre- 
sponding argument values; defined at the bottom 
of the table. 7 


Column 3 - Argument values for the device-specific word 
(I DVS) for the named device, in hexadecimal. 
See the appropriate device-specific IORB field 
value tables in Sections 7 through 10. 


Column 4 - File-indicator word argument values, in 
hexadecimal. 


NOTE: For BSC, the leading control byte allows EOT, ETB/ 
ETX, and RVI control characters, and transparent 
mode, to be sent. | 
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Table B-1. Possible Argument Values for STTY Command 
and SSTTY Macro Call 


Device/File Input/Output Operations Device-Specific | File Indicator 
Operational Mode (See Below) Argument Value Argument Value 
For TTY - 


Interactive | CR, LF, E, CB, PH, QA 0030. 3180 


0031 3180 


Interactive CR, LF, E, CB, QA 


Interactive CR, LF, E, PH, QA 0830 3180 


3180 


0831 


Interactive CR, LF, E, QA 


Forms PH, QA, PG 0cOC 3180 
Forms QA, PG 0cOD 3180 
Printer Emulation CR, E, CB, PH, QA | 0020 5180 
Printer Emulation CR, E, CB, QA 0021 5180 
Data Entry PH, QA, TR | 0C08 . 3180 
Data Entry QA, TR 0C09 — 3180 


Interactive — CR, LF, PO, CB, PH, QA, TM, PL 
Interactive CR, LF, PO, CB, QA, TM, PL 
Interactive CR, LF, PO, PH, QA, TM, PL 
Interactive CR; QA, TM, PL 

Forms 

Forms 


Forms 


Printer Emulation 


Printer Emulation 


Receive-only printer 


Receive-only printer 
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Table B-1l (cont). Possible Argument Values for STTY Command 
and SSTTY Macro Call 


Device/File Input/Output Operations Device-Specific | File Indicator 
Operational Mode (See Below) Argument Value Argument Value 
| For PVE (polled VIP emulator) 


QA, FC 
Foc BSC 

Adv anced 
Advanced 
Basic 
Basic 
Basic 
Basic 

CR - Carriage return TR - Transparent text 

LF ~- Line feed FC - Hardware function codes present 

E - Echo input characters PO - Page overflow recovery 


(home cursor) 
CB - Control byte 
TM ~ Time-out on read 
PH - Physical disconnect (hang up) 
PL ~ 1~second poll interval (ignored 
QA —- Queue abort if nonpolled line) 


PG - Page transfer (forms mode) ETB ~ Send ETB/ETX characters 
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APPENDIX C 


RESOURCE CONTROL TABLE (RCT) 


The resource control table (RCT) is the interface between 
the line protocol handler and its devices. For each line proto- 
col handler and device, the system builds an RCT that contains 
the characteristics uniquely describing that device. 


The RCT contains the physical data that the line protocol 
handler needs to interface with the device. The RCT also 
includes a work area where every line protocol handler can save 
whatever values, pointers, etc., that it needs. 


Figure C-1 shows the format of an RCT for communications. 
devices. Table C-1 defines the communications-specific items in 
the RCT. Table C-2 defines the terminal attributes and status 
field (R_STS). | 


C-1 CBO3 


Nees 


oO 9 : 
CHANNEL LEVEL 
LINE ADAPTER TYPE 

FLAGS (0) 

: DEVICE STATUS (0) 
TERMINAL ATTRIBUTES 
AND STATUS 

ADDRESS OF ATTENTION 

SUBROUTINE 

MESSAGE COUNT NAK COUNT 


R_ TYP. 


R_FLGS 


R_STTS 


R_STS 


R_ATTN 


R_ MSG 


| (RESERVED) 


CONNECT/DISCONNECT FUNCTIONS SUPPORTED | 


7 DEVICE RESERVED 


ATTENTION INTERRUPT HAS OCCURRED 


eal DISABLE DEVICE ON ATTENTION INTERRUPT 


Se 
[o romesrenrsuneeamen 
[serene 


NOTE: THE WORD R_FLGS WILL HAVE BIT 6 SET. 
INDICATING THAT THE CONNECT/DISCONNECT 
FUNCTIONS ARE ALLOWED. 


Figure C-l. Format of Communications Resource 
| Control Table (RCT) 
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Table cC-l. 


Communications— Specific Items in the RCT 


Device hardware status; mapped into 


software status word I ST of the 
(IORB) (see Table 6-3). 


Bits 0 through 7: Count of messages 
sent to and received from the termi- 
nal (maximum 256). For VIP devices, 
count includes certain control mes- 
sages exchanged on the line, thus 
does not represent the number of 
text messages. 


Bits 8 through F: Count of NAKs 


sent to and received from the termi- 
nal (maximum 256). 


Reserved for system and later use 


Device disabled by the system 


Input possible 

Output possible 

Device connected 

Device physically enabled 


Device logically enabled 
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APPENDIX D 


SAMPLE APPLICATION PROGRAMS 


COBOL PROGRAM EXAMPLES 
COBOL TTY or VIP Application Example 


The COBOL source program listing in Figure D-1 is an example 
of an interactive application that involves either VIP or TTY 
devices. 


This program (named CARCOM) processes commands entered from 
the operator terminal, and includes input/output operations to 
two communications terminals (either TTY or VIP). An input and 
output file is assigned to each device. The program uses the 
operator terminal for entering commands and for receiving error 
messages. Input/output processing messages are displayed on the 
line printer. 


COMMANDS IN THE COBOL EXAMPLE 
The program processes the following interactive commands 
received from the operator terminal. The command COMND is 


entered from either terminal 1 or terminal 2 (see "File 
Assignments" below). 
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Command : Program Action 


OPEN filename Opens the file 


CLOSE filename Closes the file 
ROUTE | Routes terminal output to other 


terminals as input 


GO : Exits command mode, looks for input 
from terminals : 


COMND Exits terminal input mode; returns to 
(entered from operator terminal in command mode 
terminal 1 or 2) | 7 


STOP Stops execution 


The program CARCOM uses the following file names and corre- 
sponding logical file numbers (LFNs): 


File Name LFN Device 
COM1IN 3 Input terminal 1 
COM1OT 4 Output terminal 1 
COM2IN od Input terminal 2 
COM20T 6 Output terminal 2 
PRINTER 1 Printer 


ERROR MESSAGES IN COBOL EXAMPLE 


When appropriate, the COBOL example CARCOM displays these 
messages, in the formats: | 


OPEN COMI1IN 3 

CLOSE ERROR FILE COM1OT ZZ - FILE STATUS 
READ COM2IN 

WRITE | COM20T 


ZZ = File status code 


Program actions resulting from these messages are: 
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OPEN or CLOSE mesSage: 
Returns control to the operator terminal 
READ or WRITE message: 


Tries the I/O operation four times; then close the 
file and return control to the operator terminal 


STATUS CODES IN COBOL EXAMPLE 
The program CARCOM includes checks that verify operation of 
COBOL error returns and information status returns. The check 


codes are: 


9I - For a read operation, indicates there iS no data. 


For a write operation, indicates that the device is 
busy. | 


95 - Record length error. 
EXECUTION OF COBOL TTY OR VIP PROGRAM EXAMPLE 


When the program begins to execute, the operator terminal 
displays the message: 


TYPE COMMANDS, THEN GO. 
At least two files on the same device must be open to pro- 
ceed to the next level of command input. At this level, the pro- 
gram displays the message: 


COMMANDS? 


The operator may then enter commands to: (1) open files; 
(2) close files; (3) route (message switch); (4) activate the 


read/write loop; or (5) stop. 


NOTE: Activating the read/write loop deactivates command 
input from the console and causes the application to 
check open terminals for input. 


To return to the command level, the operator types COMND 
from an active terminal. 


A typein from a remote terminal is echoed back to that 
terminal and displayed on the second terminal. 
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GCOS6 


SOURCE 


ODOOner Now = 


10 


COROL 


“PROGRAM 


TDENTIFICATION DTVISTON, 
PROGRAM=TD. CARCOM, 


* 


COROL COMMUNTCATTONS 


FNVIRONMENT NIVISION, 
CONFTGURATTON SECTTON, 
SOURCE=COMPUTER. HTS#SFRTES=40 LFVFL=6. 


* 


NBJECT=CNMPUTER, HTS=SFRTIES=40 LFVFL=6. 


-TNPUT=NUTPUT SECTION, 


FILE*CONTROAL, 


* 


SELECT COM1IN 
ASSIGN TA OC=MSD, 
ORGANIZATION IS SEQUFNTIAL WITH VLP, 
ACCESS MADF TS SFQUENTTAL, 
FILE STATUS TS INI@STAT. 


SELECT COMIOT 


ASSIGN TN ND=MSpD, 
ARGANIZATINN JTS SENUFNTIAL, 
ACCESS MODF TS SFQUENTTAL, 
FILE STATUS TS OT1=STAT. 
SELECT COMAIN 
ASSIGN 10) NEEMSD, 
ARGANI7ZATION IS SEQUFNTIAL WTTH VLR, 
— ACCESS MODF TS SFQUENTTAL, | 
FILE STATUS TS IN2=STAT. 
SELECT CNAM?0T 
ASSIGN TON OF=MSD, 
NARGANIZATION IS SENUFNTIAL, 
ACCESS MNDF TS SFQUENTTAL, 
FILE STATUS TS OT2-STAT. 
SEN ECT PRINTFIIE 
ASSIGN TN NA=PRINIFR, 
ARGANIZATION IS SEQUFNTIAL, 
ACCESS MODF TS SFQUENTTAL, 
FILE STATUS TS PRT=STAT. 


DATA OTVTSTON, 


x 


FILE SFCTION, 


FD 


01 


FO 


Figure D-l. 


fOMIITN 
RLACK CONTAINS 1 RFCOARNS, 
LAREI RECORDS ARF OMTTTED, 


TNI@REC PI ¥(RO). 


FOMIOT | 
RLACK CONTAINS 1 RFCOARNS, 
1ARE! RECORDS ARF OMTTTEN, 


M2 CTL1 PTC XX. 
N2 OAT1eREC PTC YXC(RO). 


COM2TN 

RLACK CONTAINS 1 RFCORNS, 
LAREL RECORDS ARF OMTTTEN, 
TNP MRE PIr YxX(AO0), 


coment 


RLOCK CONTAINS 1 RFCORNS, 
LAREL RECORDS ARF OMITTED. 
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CBO3 


ABS a> 


1 


91 
* 


NUTCOM2-REL, 
NM? fFTLA? PIF Xx, 
N12 NTP-REC PTC ¥X(AO0). 


PRINTFILFE 

RLOCK CONTAINS 1 RFCARNS, 
LAREL RECORDS ARF OMTTTEN, 
PRT@=REC PTC ¥X(120). 


WORKING=STNRAGF SECTTON, 


M1 


1 
1 
0} 
ny} 
1 


01 


01 


a | 


M1 


Figure D-1l 


CTITLE. 

M2 ‘FILLFR PIC XY VALUE SPACES, 

Me FIULFR PIC X15) VALUF "COBOL COMM TEST", 

CCMND1. | 

02 FILLFR PIF XX VALIIE SPACES. 

M2 FILLFR PIC X27) VALUF “TYPF FILE COMMANDS, THEN GO", 
Me FILLFR PIF XX VALIIE SPACES. 

CCMNDO, 

M2 FItItFR PIF XY VALITE SPACES, 

NM2 FFILLFR PIF X&) VALUE "COMMANN?", 

HEAD. 

M2 FILLFR PIF XS?) VALUF SPACFS, 

M2 FIUtLFR PJF X18): VALUF "CNBONL COMM TEST", 

NM? FILtLFR PIC xX(S%) VALUF SPACFS, 

N2@ FILLFR PIC xXx(5%) VAILUF SPACFS, 

HDR, 

N2 FIULLFR PTC X(6) © VALUF SPACFS, 

N2 FILLER PTC X27) VALUE “xaex TNPUT MSG FILE: ",. 
02 HDREFIL PIC ¥(6) VALUE SPACES, 

HDR, 

M2 FILLFR PTC Xfo) -VALUF SPACES, | 

02 FIULLFR PTC X(2R) VALIIE “xxex NUTPIUT MSG FILE: wie 
N2 HORSFIL PIF Y¥X(4) VALUE SPACES. 
1O4DCOMP, | | 

M2? FILLFR PIF XX VALIIE SPACES. : 

M2 >FItLFR PYF X13) \VALUF "LOAN COMPLETE", 
CONIN, 


_ 2 CMNFLD, 


93 GOIFLD PIC x2) VALIIE SPACES. 
9%§ FILLFR PIC XxX3) VALUE SPACES. 


02 ‘FILLFR PIC X VALUF SPACFS. 


02 FILFLO PIF xXf6) VALUE SPACES. 
CONINI RFOFFINES CONTN. 

02 FILLFR PIF X(S). 

02 FILFLD1 PIF Xb). 

NSK=REC. 

02 TTFMNUM PIC XXX VALUF SPACFS, 
02 FILLFR PIC XX VALUE SPACES. 
02 NESCFLD PIF x20) VALUF SPACFS. 
02 FILLFR PIC XX VALUE SPACES. 
02 ATYRFD PIF 9999 VALIIE ZFRO. 
02 FILLFR PIF X30) VALUE SPACES. 
TNI=STAT PTC XX  VALUF SPACFS. 
AT1-STAT PTC XX VALUF SPACFS, 
TN>=STAT PTC XX  VALUF SPACFS, 
NT2<-STAT PTC X¥ VALUF SPACFS, 
PRT@STAT PIC XX VALUF SPACES, 
ROR-STAT PTC XX VALUF SPACFS. 


TNVF=STAT PTC YX VALUE SPACFS, 


RKF Ye] PTC 999 VALIIE ZFRN, 
No-IT PTC XX VALUF "GN", 
OPNFTL PIC XG) VALIIE "NPEN", 
CLSFTL PIC x(5) VALUE "CLOSE", 
LOADF PTC *¥*(4) VALUF ®LOAAN", 


(cont). COBOL TTY or VIP Application Example 
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1?6 77 
1?7 77 
128 77. 
129 77 
130 77 
131 77 
132 77 
133 77 
134 77 
135 77 
1%6 77 
137 77 
138 77 
139 | 77 
140 77 
141 77 
142 77 
143 77 
144 . 77 
145 77 
146 77 
147 77 
148 77 
149 77 
150 77 
151 77 
152 77 
153 77 
154 77 
155 77 
156 77 
157 77 
158 77 
159 77 
140 77 
1461 any a 
142 77. 
163 77 
164 77 
145 77 
166 & 
167 01 
148 
169 
170 N1 
171 
172 
173 
174 
175 M1 
176 
177 
178 
179 
180 
181 
182 a | 
183 . 
144 
185 
186 
187 
188 | 
189 Ni 
Figure D-1 


FNDER 
TN1 


nT! 
TN? 
0T? 
RORF PIC. 
TNVFE PIF 
WHN|EARN P 
WHN@FRR Pp 
FILCOUNT 
RTFFLG 
ROUTE P 
COMDNM 
KEYEN 
RDKYAIM 
NORNERCMD 
HPNATCMD 
NTSPTTM 
CCCHAR 
NOTIFY 

Swit TCH! 
SWITCH? 
TNVSWTCH 
TRNSWTCH 
STATING. 
STATNT! 


PTC 
PTC 


PTC 
PTC 
PTC 


STATING 


STATONT?A 
FRSUMITN 
FRSUMINT 
FRSUM2TN 
FRSUM2NT 
SUM9T1 
SUM9T2 


ATYSIIB PY 


NMCKRSLT 
MAYXNUIM 
MAXITMNO 
MAYQTY 
CHKANIIM 


TNSPFCTI. 
02  TNCMD 
02 FILLER 
APNSPL. 

N2 FILLER 
02 OFLNAM 
M2 FILLER 
02 FILLER 


—OPFROSPL. 


NM2 FILLER 
M2 FILLER 
N2 OFLNFR 
M2 FILLFR 
M2 FILLFR 
(1? KEYERR 
PDFRMSG. 

M2 FIILFR 
M2 FILLFR 


X(4 
XA 


) 
) 


X(6) 
¥ (4) 
¥(6) 


X(6) 
X(6) 
TC 9 
Tc 9 
PIC 
PIC 
Tc XxX 
Pir 
Pir. 
PIC 
Pir 
PIC 
PIC 
PIC 
PIC 
PTC 
PTC 
pir 
PIL 
PTC 
PTC 
PTC 
PTC 
PIC 
PIC 
Pre 
Pir 
Pir 
PIr 
r 86s§9 


PIcr 
PIr 99 

PIC 
PIC 
PIC 


PTC 
Pir 


Pir 
PI. 
Pir 
Pir 


PI 
PIr 
err 


Prt 


err 
PIC 


PIC 
PIr 


SEQ; 

"COMIIN", 
"COMIOT". 
*CNMAIN", 
"CNMPOT". 


VALUF 
VAL UF 


VALUF 
VAL UF 
VALUF 


VALUE "CAPDTA™. 
VALIIE “TNVFTE™, 


V 
V 


ALUE ZFRN, 
ALIIE ZFERN, 


99 VALITIE ZFRO. 


99 
(5S) 


X(5) 


X14 
x4 
x X 
xX 
xx 
X 

999 
99 
99 
99 
99 
a9 
99 
99 


Q9. 


99 
99 
99 
99 
9C4 
9(4 
999 
9 
99 
999 


9999 
9999 


¥( 
x 


xX 
x 
x 
X 


X 
x 
x 
xX 
X 
x 


x 
x 


VALIIE ZFRNA, 

VAIUF "ROUTE". 
VALUE "COMNND®, 

3) VAtUF 

%) VAILUF "INVALTD KFY= 
VALUE "A ™, 

VALINE “tr * 
VALIIE "A", 

VALUF "A", 

9 VALITIE 9999, 
VALUF 7ERO, 
VALUF ZERO, 

VALITE ZFRA, 

VALIIE ZFRA, 
VALUF ZERO, 
VAIUF ZERO, 
VALUF ZERO, 
VALUF ZERO, 

VALIIE ZERO, | 

VALIIE ZFRNA, 

VALINE ZFROA, 

VALI'E ZFRO, 

Y. VALIIE ZERO, 
») VALIIE ZFRO, © 
VALUF ZERO. 

VAIUF 7JERO. 
VALIIE ZERO, 

VAI UF PON, 
VALIIE 1909, 
VALIIE ZERO, 


S) VAtLUF SPACFS, 
(75) VALUF SPACES, 


X VALUE SPACES. 
(6) VALIIE SPATES. 


X¥ VALIIE SPACES. 


(6) VALINE "OPFNFD". 

¥ VALUE SPACES, 

(19) VALUF “OPEN FRROR 
(o) VALUE SPACES, 

(6) VALUE SPACES, 

(8) VALUE “STATUS= ". 
¥ VALIIE SPACES, 


Y VALIIE SPACES. 
(19) VALUF “RFAN FRRUR 


N2 ROFRF II. 
NM? FILLFR PIC 
NM? FItLFR PIF 
02 RDERSTAT 
WRFERMSG. 


(cont). COBOL TTY 


PTC X(€A) 
X(6) 
x8) 


PI xX 


VAILUF SPACFS, 
VALIIE SPAFES, 
VALNIE “"STATIHIS= " 
VALIIE SPACES, 


"RFLATTVFE KEY ". 


FILES: 


FIVE: . 


or VIP Application Example 
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‘tt 


esi 
252 


Figure D-1l (cont). 


n2 FILLFR Ir x¥ 
N2 FILLER eC 


NO WRFERFII PTC Y(A 
M2 FItLtFR PIF Xo) 
NM? FILLFR PIF xB) 
NO WRFRSTST PIR xy 
Ni CLOSPL. 
N2 FILLFR PIF XX 
NO FLNAM PIC x6) 
NQ2 FIJLLFR PIF XY 
N@ FILLFR PYF Xo) 
Ni LERMSG. 7 
02 FIItFR eT xX 
N22 FILLFR PIF 
M2 CFLNFR PIF Xo) 
Ne FJILFR PIC Xb) 
AQ FIJILFR PYF XB) 
N22 CKFYFRR PTC ¥X 
N11 BANFIL. 
fie FIILFR pie xv 
NO FILtLFR PIC XA 
N1 RANCMO, 
2 FIILFR PIr. x¥ 
No FItcFR OFF KM—.S 
A, MOTESUM, 
N12 FYJtLFR PIF XY 
M2 FILLFR PIC Xo) 
ND? EFRROT pir X(A 
N2 FILLFR PIF Xo) 
M2 FIJILFR PFT XIN 
Ny STNPCOR, 
NV? FIULLFR PIr x¥ 
Ne FILLER PI X10 
01 KEY=eMSEG. 
NM? FItLFR PIF ¥(16) 
N2 RANeKEY PIC YX 
NO FIIELFR PTC X12 
‘ 
PROCFDURFE NIVISIAN, 
x 
PHFANS, 
MOVE CfECHAR TO CTL!. 
MOVE CCCHAR TO CYLP. 
NISPLAY CTITLE. 
OPEN OUTPUT PRINTFILF. 
MOVE HFANL TN PRT-REC. 


X19) 


x19) 


VALITE SPACES, 
VALUF “WRITE ERROR 


) WALUF SPACFS, 
VALITE SPATES. 
VALIIE “STATHS= ", 
VALIIF SPACES, 


VALE SPACES, 
VALIIE SPACES, 

VALNE SPACES. 
VAL'IE "CLOSFD". 


VAL'IE SPACES, 
VALUF "CIOSE ERROAR 
VALIIE SPATES. 
VALIIE SPACES. 
VALIIE "STATHIS= ". 
VALUF SPACFS, 


VALE SPACES, 
) VALUF "ILLFGAL FILFNAME®, 


VALIIE SPARES. 
) VALUF “TLLFGAL COMMAND", 


“VALITE SPACES. 


VALUE “FItE: ™. 

) VALIIE SPACES. 
VALIIE SPACES, 

) VAtUF “STATUS= 9T", 


VALUE SPACES. 
) VAtUF "STOP FOROL". 


VALITE “FILE KFY STATUS "™. 
V4ALITE SPACES, 
) Value " TEST FAILEN®, 


WRITE PRT=REC AFTER ADVANCING PAGE. 


PCMO1. 
NMISPLAY CCMNN1, 
MOVE SPACES TO CONTN, 
ACCEPT CONTN, 
TF CMDFLN TS EQUAL TA 
TF CMDFLA TS ENVAL TA 
NISPLAY RANCMD, 
G0 TO PCMDI. 
PCMD?. 
NISPLAY ECMNDO2, 
MOVE SPACES TO CONTN. 
ACCEPT CONTN. 
TF CMDFLOD TS ENUAL TA 


TF CMOFLN 
TF CMDFLN 
TF CMOFLDO 


TS EQUAL 
TS ENUAL 
TS EQUAL 


TA 
Tn 
Tn 


COBOL TTY 
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OPNFTL GN TO OPENIT. 
CLSFTL GN. TO CILOSIT. 


NPNFTL GN TO OPENIT. 
CLSFTL GO TO CLOSIT. 
ROUTF GO TN SETROUTE. 
NO-IT GO TN READ. 


or VIP Application Example 


Files 


Fille:.* 
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253 
254 
255 


256 
257 
258 
259 
260 
261 
2b2 
263 
264 
265 
266 
267 
268 
269 
270 
271 
272 
273 
274 
275 
276 
Pa 
278 
279 
2A0 
2A 
2A2 
2A3 
2A4 
2A5 
26 
2A7 
2R8 
2A9 
290 
291 
292 
293 
294 
295 
296 
297 
298 
299 
300 
301 
302 
33 
304 
305 
36 
307 
308 
309 
310 
311 
312 
313 
314 
315 


NISPLAY RANCMD, 
GO TO PCMD?. 
APFNITT. 


TF FTLFLO1 IS FQNAL TO INI 6M TO OPIN, 


TF FILFLO1 IS FAUAL TO OTL GA TO OPOT1. 


TF FILFLO1 IS FQUAL TO IN2 GA TO OPINA, 
TF FTLFLA1 IS FQUA!L TO-OT2 GA. TO OPOTe2. 
DISPLAY RANFTL, 
TF FILCONUNT GREATER THAN 1-69 TO PCMM2, 
GO TN PCMDI, 7 
NPTN1. 
NPFN INPUT COMIN, 
TF IN-STAT = "00" OR TN1=STAT = "95"%3 
MOVE 1 ‘TN STATINIS 
MOVE 1 TN SwTTCH3 
MOVE IN1 TN AFLNAMS 
60 TN NPMSE. 
MOVE IN1 TA AFLNFR, 
MOVE IN1@STAT TO KFYFRR, | 
G0 TN NPFRMG, 
NPNTY. 
OPFN OUTPUT fFOMINT. | 
TF OTI=-STAT = "ON" OR NT1-STAT 
MOVE 1 TN STATOTI3 | 
MOVE OT1 TO NFULNAMS 
RO TN OPMSF, 
MOVE OT1 TAN NFLNFR, 
MOVE OT1-STAT TO KFYFRR, 
GO TN OPFRMG, 
NPTN?. | 
OPEN INPIIT COMPIN, 
TF INQ@STAT = "00" QR TNPHSTAT 
MOVE 1 TN STATIN? 
MOVE 1 TON SWTTCHP; 
MOVE IN2 TO OFLNAM? 
G0 TO OPMSG. 
MOVE IN2 TON OFLNFR, 
MOVE IN2=STAT TO KFYFRR, 
C0 TO OPFRMG. 
NPNT?P. 
OPFN OUTPUT COM2NT. 
TF OT2=STAT = "ON" QR ATPH=STAT = "95"; 
MOVE 1 TN STATOT?P3 
MOVE OT2 TA AFI NAM? 
60 TN OPMSE, 
MOVE OT2 TN NFLNFR. 
MOVE OT2=-STAT TO KFYFRR, 
GO TAN OPFRMG, 
OPMSR, 
NISPLAY OPNSPL. 
ADM 1 TO FILFOUNT, 
TF FILCOUNT RRFATER THAN 1 GN TO PCMN2, 
60 TN PCMDI, 
NPFRMG, | 
NISPIAY ANPFRNSPL. 
TF FILCOUNT GREATER THAN. 1 GO TO PLMN2, 
GO TN PCMDI. 
CLOSTT,. 
TF FILFLA TS EQUAL TN TN1 GO TN CLINI. 
TF FYLFLA TS EQUAL TN AT1 FO TN CLATI.L 
TF FYLFLO TS EQUAL TA TN? FO TA FLINA. 
TF FILFLA TS ENUAL TN NT? FO TA LATA. 
NISPLAY RANCMD, 


"Q5"3 


"Q9S"3 


Figure D-1l (cont). COBOL TTY or VIP Application Example 
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a 


Ne ot 


316 
317 
318 


319 © 


320 
301 
3?2 
3°3 
394 
3°5 
3?6 
3°7 
378 
329 


—3540 


331 
332 
333 
334 
335 
3%6 
337 
338 
339 


340- 


341 
342 
343 
344 
345 
346 
347 
348 
349 
350 
351 
352 


353, 


354 
355 
356 
357 
358 
359 
360 
361 
342 
343 
364 
3465 
$46 
367 
348 
369 
370 
371 
372 
373 
374 
375 
376 
377 
378 
379 


TF FYLCOUNT FRFATER THAN 1 GO TO PFMNRe, 
FO TNO PCMDI. 

CLIN. 
CLOSF COMITN, 


TF INI©STAT = "QA": 
MOVE ZFRN TO SWITCHI13 
MOVE ZFRN TO STATIN 1: 
MOVE INi TN CFLNAM? 
680 TAN CLOAPMSE., 

MOVE IN1 TO CFLNFR, 

MOVE IN1I=STAT TO CKEYERR, 

LO TN COPERMG, 


~FLOTS. 


FLOSF COMINT, 
TF OTI=STAT = "ON"? 
MOVE ZFRN TO STATOTI? 
MOVE OT1 TON CFLNAMS? 
560 TN CLAPMSE, 
MOVE OT1 TN CFLNER. 
MOVE OTiI=-STAT TO CKEYERR, 
60 TN COPERMEC, 
CLINA, 
CLOSE COM2TN. 
TF IN2=-STAT = "ON"3 
MOVE ZFRN TO SWITCH23 
MOVE ZFRN TO STATIN; 
MOVE IN2 TN CFLNAM?: 
£0 TO CLOPMSE. 
MOVE IN2 TN CFULNFR. 
MOVE IN2-STAT TO CKEYERR, 
FO TN COPERMS. 
CLOTP. 
CLASF COM2NT. 
TF OT2-STAT = "ON"? 
MOVE ZFRN TO STATOT2? 
MOVE OT2 IN CFINAMS 
GQ TA FLAPMSE, 
MOVE OT2 TN CFINFR, 
MOVE OT2-STAT TO CKEYERR, 
F060 TN COPERMEF, 
FLOPMSS, 
NISPHAY FCLASPL, 
SURTOACT 1 FROM FILCOAUNT, 
TF FILCFUUNT GREATE® THAN 1 GON TO PMN, 
FO TA PCMDI. | 
COPERMA, | 
NISPLAY CLERMSSC, 
TF FIYLCOUNT GREATER? THAN 1 GA TO PFMNA, 
F0 TA PCMDI. 


SETROUTE, 
TE STATIN} = 1 AND STATOT2? = 1 GA TO OKSFT, 
TF STATINS = 1 AND STATOTL = 1 G69 TO OKSFT, 


NAISPLAY 8AaNCMN, 
FO TAN PCMD?, 

NAKSET, 
MOVE 1 TM RTFFIG, 
LO TN PCMDP, 

READ, | 
TE FYLFOUNT = ZERO GO TO PFMA1, 
TF SWITCH] = ZFRO GO IN READ, 
MOVE SPACES TU IN1L=RFC, 
READ COMIIN AT E™"6 GA TO DANFIT, 
TE I"teSTAT = "00" G6 TO GNONRI, 
TE INZGeSTAT = "QGT"3 


Figure D-1 (cont). COBOL TTY or VIP Application 
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3R0 
3A1 
3R2 
3R3 
3RY4 
3R5 
3R6 
3R7 


388 


389 
390 
391 
392 
393 
394 
395 
396 
397 
398 
399 
yng 
an} 
4ne 
43 
ang 
ans 
46 
4n7 
498 
409 
410 
411 


412 


413 
414 
415 
416 
417 
418 
419 
4?0 
4? 1 
4?2 
4?%3 
Qed 
425 
4?6 
4?7 
4?8 
4?g 
430 
4%1 
432 
433 
434 
435 
4%6 
437 
438 
439 
440 
Qa 
442 
G43 


| RO TN READ, 
MOVE ZFRN TOU StIMOT1, 
MOVE INJ=STAT TO RNERSTAT. 
MOVE ING TA POFRFII. 
NISPLAY PDFRMSE, 
ADN 4 TO ERSIImMIIN, 
TF EPSIimMg IM NOT LESS TRAN 4 GO TA CLINI. 
OFA, 
TF SWITCH2 = ZFRA FO TN PEADI, 
VOVE SPACES TO IN2@-RFC. 
PEAD CNmPIN AT END GOA TO DANFIT, 
TE IN2Q=STAT = "09" GA TO GANUDR?, 
TF IND=STAT = "QTM? 
RO TA PEADI, 
MOVE ZERO TO Stimay, 
MUVE IN2=STAT TO RMPERSTAT. 
MOVE IM2 TA ROFRFIL. 
NISPIAY ®PDFRMSE, 
ADM § TO ERSUMAIN, 
TF ESS'IIMPIN NOT LESS THA" 4 BO TA CLIN?A, 
F0 TN PE4ADI. 
RONHR1. 
MOVE ZFRO TO ERSIIMITIN, 
MOVE ZFRN TO S!ilmort. 
PERFNRM PRITINY THRE CHKOTPT1. 
MOVE JTNi=RFC TAO TNSPFCTI. 
TF INCMD IS FaQtial TO CAMNANY RU TNA PCMD?A, 
TF RTEFLA TS NAT ENUAL TN ZERO? 
MOVE INI=RFC TN NTP=-PEC; 
GO TN WRITFO, 
MOVE IN1@RFC TN NT1-PEL, 
GO TN WRITF1, 
PRTIN1, | 
MOVE INY TON HDRPAFIL. 
MOVE HDR? TO PRT-RFC. 
WRITE PRT-PET . 
MOVE SPACES TU PRT=RFC, 
MOVE IN1"©RFC TO PRT-PEC, 
CHKOTPTI, | 
WRITF PRT-REC, | 
TF PRT-STAT = "QT" GN TO CHKOTIPTI. 
WRITE, 
WRITE NUTCOIMI@REC, 
TF OT1-STAT = "ON" GN TO WRTTOK, 
TF GT1-STAT = "9T" GOA TO WAITES. 
MOVE OTI=STAT TO WRERSTAT. 
MOVE OT1 TA WRFRFI!I. 
NISPLAY WRERMSC, 
ADN 1 TA ERSIMIOT, 
TF ERSItIMIOT NOT LESS THAN 4.60 TA FLATI,Y 
CFO TN READ?, 
WRTINK, 
MOVE ZFERN TO E2SIIMIOT, . 
PERFNARM PRTOTI THI! CHKOTPOY, 
CLO TN READ, 
PRTOTI. 
MOVE OT1 TOM HORZFII. 
MOVE HAR TO PPT@RFC. 
WRITE PRT=PE, 
MOVE SPACES TU PRT=RFC. 
MOVE OT1=RFC TO PRT@PEC, 
CHKOTPNY, 
WRITF PRT@PEL . 
TF PRT-STAT = "9T" GN TO CHKOIPOI, 


Figure D-1 (cont). COBOL TTY or VIP Application Program 
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G44 CONDP 2, 
44s MOVE ZFRN TO EPSIIMAIN, 
446 MOVE ZFRNAN TO SIIMo]q?, 
447 PERFARM PRTIND THRI) CHKOTPT2, 
448 MOVE IN2-RFC TO TNSPFCTI, 
449 TF INCMD 15 FOQUAL TO COMNNM GO TN PCMD?A, 
450 TF RTEFLG TS NOT ENUAL .TN FEROS 
451 MOVE IN2=RFC TN AT1=PEC; 
4Se2 GO TA WRITFA, 
4S3 MOVE IN2@=RFC TN ATA-RPEF, 
454 FO TN WRITFO, 
455 PRTIN2, 
4S6 MOVE IN2@ TO HOROFTI. 
4S7 MOVE HNRAP TO PRTmRFC. 
458 WRITF PRT=-REL, 
4s9g MOVE SPACES TO PRPT=RFC,. 
460 MOVE IN2@"RFC TN PRT-REC, 
461 FHKOTPT2, 
4be2 WRITTF PRITeRES, 
463 TF PRT=-STAT = "9T" GN TO CHKOIPI?, 
4Ad WRITFO, | 
“6S WRITE NUTCNMPHPEC, 
466 TF OT2-STAT = "09" GN TO WRT?P0K, 
467 TF OT2=STAT = "9T" GN TO WRITE?P, 
448 MOVE OT2=-STAT TO WREPSTAT. 
469 MOVE OT2 TA WRERFI!. 
470 NMISPLAY WRERMSE, 
a7 ADN 1 TO ERSHIMAQT, 
472 TF ERSIIMPOT NOT LESS THA" “4 GO TN FLOATS, 
473 FO JN READ, 
Q7a WRTONK, 
47S MOVE ZERO TO ERSIIM2ANT. 
476 PEPFONRM PRTQOTOD THRII CFHKOTPND, 
477 CO TA READI. 
478 PRTOT?., 
479 MOVE OTP TA HDPZFIL. 
4RQ MOVE HAR TO PRT RFC, 
uR4 WRITE PRT@REr, 
4Ao MOVE SPACES TO P®PT=-RFC. 
GAs MOVeE OTPH-RFC TN PRT=REC, 
yay CHK QTPNO, 
YRS WRITF PRT=-PEC, 
URS TF PQOT=STAT = "QT" GA TO CHKEI POA, 
4A7 NONETT, 
4AB AITSPLAY STAPFOR, 
uRg STAP RIIN, 
490 Fan rgoRg! 
NQ DTAGNOSTICS 
GCOS6 COROL 
FYTLE MAP 
LINF CLFN IFN 
11 0% OfeMSN COM1IN 010% 
146 04 QNeMsNn com10T QOTFR 
21 0S OFeMSN CNMAIN 0224 
26 0A OFeMSN COmM?POT 024° 
31 QOA=PRINTEP PPINTFIIE 0° 7A 


01 


Figure D-1 (cont). COBOL TTY or VIP Application 
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8Nn 
81 
Bn 
81 
129 


Example 


CBO3 


‘COBOL BSC Application Example 


The source program listing in Figure D-2 is an example of a 
COBOL communications program to test BSC file transmission by: 


l. Generating records 
2. Transmitting the records over one communication line 


3. Reading them back over another communication line for 
comparison 


The program name is BSCTST. -When executed, it displays the 
following error messagesS, aS appropriate: : 


Error format l: 


BSC TEST FILE- | INPUT | PROB LEM- an STATUS - 22 


OUTPUT CLOSE 
READ 
WRITE 
2z=91 - Device busy 
zzZ=00 - Program may read or write 


Program action: Issues reads and writes four times; then 
| the file is closed and the program 
terminated. | | 
Error format 2: 
BSC - TEST - NO MATCH RECORD nnnn 
Program action: Reading application does not receive the | 
expected record; records out of sequence or 


garbled. 


File is closed and the program terminated. 


D=1.2 CBO03 


ys an 


GCNS6 Foro 
SOMROE PRAGIAM 


TOFNTIFEICATION DY VTISTUM, 
PRAGOAMeTD, HSCTST, 
e THIS TS A POOLRAM WHICH TESTS #SC FILF TRANSMTISSIAN o 
@ TT NOFS SA Ry GENERATING PEFURDS , SENDING THEY (iy 
& AND HRINGING THEM BACK Th FOR ( OnPAO] Sm 
& NK A MIRF ANETATL FL) DFESCHTT TOS OF FEO Tr THE Gos ALS 
s TFST SPFECTETCATTO® FD CORO! CuUMVMiInTOATTASs 
ENVIOONMENT ATVISIAA, | 
CME TGURATT UM SECT Tye, 
SOUR E MR CAMBPI TEDL HITS eSE RTE Se Ky LFvFLma, 
OM TEE TA COMPUTE OL HTS HSER TESeAG LEVEL en, 
a 
TRHEUT]HNYUTPHIT SEC TIAN, 
FIPESCONTROAL , 
& 
SFI RFF] Toistt} Out 
ASSTGN TON AY, 
AREANT7ZATION TS SEQUENT LAL aTpre wee, 
ACFESS TS SENUFA TIAL, 


CFrnN TNT EWN KH TCH TEN TFTIMNOSOWN = 


PU Erte STATUS TH LitpeSTaT, 

P 1 SELECT Tepttriry 

Pe ASSTAY pa Ai, 

a3 ARCANE ZATIOR JTS Spe TL ree wy wy w, 

4 RETR SS TS SENUET,TIAL, 

PS Filt STATUS TH Je STAT, 

A 6 t 

27 NaTA NT VTSTUM, 

PR ft 

a9 Frté SFC TIAN, 

av Fi) TeNYTPIIT 

1 PLOACH FOMTAINS | WEE ORAS, 

%? PARE PET YOYS ARE STAARNAPL. 

33 nj AWTeES PIF vc aud, 

tq t 

ws Fi) TeV iOuT 

% RLACK CONTAINS 1 RECARNS, 

27 PASEL PEFORDS BREF STAND AOD, 

38 M1 TNeRFC PTC xO), 

39 x 

AO WOPKINGeSTARAGE SEFTTUNM, 

NY rn 

A? 77. TneSTAT Oy]r yx VAIUF SPACES, 

4% 77 «NyTeSTAT PLC xx VALUE SPACES, 

Na 77 MAYe(CNT PTC 99°99 VAL'IE 190901. 
as 77 We TNOUT PTC X(6) VAL'IE "TNEUT ™, 
46 77 WeNUITRIIT PIT ¥(A) VatuF "OUTPUT", 
47 77) WeNPFEK Pir ¥(S) VALUF "QPEN ", 
48 77 WefLASF PTC x5) VALINE "FLOASE®, | 

ag 77 WeREAD PIfr y¥(S) VAILUF "RFAD ", 
S0 77 = WelRTTE pTC x5) VALI "WRITE", 
S1 1 TEST=RFC, | 

So . NP FILLFR PIF ¥(t2ey VALIIE "TEST RFCARD ", 

83 NO TReC"T PIF 9999 VATUF 7EPQ. 

Sa NO FILLFR PIf Y¥(Sa) VALTIE SPACES. 

SS M2 FILLER PTC Xf19) VALE “shee eaeeen, 

S6 | M1 FOFeRET, 

97 NP FYLLEP PIF ¥(%) VALIIE SFOF®, 

Sa fe FILLFR PIF ¥(77) VALTIIF SPACES, 

59 Nj FRemSGt, 


Figure D-2. COBOL BSC Application Example 
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Figure D-2 (cont). 


n} 


a1 


* 


Nn? FILLFR PTC XC JA) 
N12 FeFTI1€ yf Y(A) 
Ne FIILFER PTC x19) 
N2 FeTYPFE PTC x5) 


Nn? FTILFR Pir y¥(9) 
AQ FeSTAT PTC XY 
FremMSG?,. 


Ne FTILFer 
AP? RBan-oeer 
FU T=”Sf, 


PIF ¥(?8) 
DIF ACA) 


VALIIE "RS TEST= FIlE= ". 
VALIIE SPACES, 
VALHE ™ PRURLEM= ", 
VALUF SPACFS, 


VALUF ™" STATIS] ™, 


VALE SPACES, 


VALUE 7FEEUES, 


NP FILLED PIF ¥(%) VALTER "ASF Fu te , 
AP FINALHEC"T PTC 9fud VAIUF Z7ES0FS, 


NO FETLIEFP PYF Y¥EPHY Val UF 


PRACEDHWE MIVISIAN, 
HSFRKFEP, 


MOVE ZERPES TQ TO=Cnt. 


APFNeUP, 


MPF INPUT T-TMPHT, 


Te TMeSTAT ANT FAME "AUON;G 


RO FAO TNeFPR, 
APEN GHTPUT TeAUTRIT, 
TE UlIT=STAT “GT Fistlat 

BQ) 1M NUT]er RP, 


" DEFOR DS TRANSMTTTEN", 


MAYFE WeNPEN TO FebTyPE $s 


"Ons MOVE weQPFt TO E-TYPFs 


TReCMN] TN FNAL @ONTS- 


CluSkeuh, 
AMPAPE . 


t 
* 
VASTFER.,. 
ADN 1 TH JRoeFyT, 
MOVE TFSTeREF TU ONTHKEC, 
PEAY. ) 
PEA) Teg stpliyT aT FRiNs weave 
NTSPLAY Furte sf 3 GA TU 
TE J[NeSPAT = "NO";Z BA TH C 
TE [M=eSPTAT = "QE"; 49 Th wOTTet, 
VOVE werFAND Ty FelYRE, 
Bo IV Tarek Rr, 
WRTTEY | 


WRITE NuTHOEe, 

TE OUTeSTAT = "GN"? RU IN 
TF BNTeSTAT = "oT"s LO TA 
Vie wesOT Ter TO FeTyOt, 
My Ja NyTeEhQ, 


CIPMPAKE 


Le eR re ATS eee 
TR (Pew FEC st RUF MKF OO 
MEW bE TOeNT TE, thle k El, 
ATSpPt AVY FWer SA 
hie JN STL NwM eb, 


oO i a aan ee a Pe ee 
MVE EMeSTAT TO FOSTAT, 
iy TA NpeMSt., 


NTeoeF RO, 


YVOVR AeutlPOutT Tie beb TF, 
MOVE ullf=STAT Tir FeSTAT, 


NP=M&G, 


NISPIAY FR=MSG1, 
LO TN STNP-PR, 


Cl QSet-uUP., 


FLOASF Tel NPUT, 


COBOL BSC 
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COMPARE , 
WRTEF OD. 


T7 TpeSTeonFe sc Co 19 "ASTE ©, 


Le EL OSE os 


Application Example 


VOLE "RSF TEST= My MATCH, PEF URD= ". 


CB03 


( 173 TF TN@STAT TS NUT FQllal "OO"! MOVE weClOSt TO F-TYPF? 


174 fO 19 TNeERPR, 

125 £O TA STANPOPL, 

1°6 CLOSFe, 

1?7 FLASE TeNUTPHIT,S - : 
1784 TF O'ITH=STAT TS NOT FENUAL “AUT, MOVE WelLNSE TY FHT YPE; 
1?9 BO TN NUTHFRE, 

1%0 £0 TAO MASTER, 

131 

1%2 STONPOPL, 

133 STOP RIN, 

134 FANN CURmOl , 


NO DIAGRNASTICS 


GCFOS6 FORUt 
FILF MA, 
L INF LEN IFN 


14 09 UT=e4Sn T-O'NTPUT VAQGE wn 
Pde | 19 ANeMSN Tel pity 09C7 nO 


Figure D-2 (cont). COBOL BSC Application Example 
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FORTRAN Application Example for TTY 


The FORTRAN source program (program name FORCL4) listing 
shown in Figure D-3 is an example of a FORTRAN application pro- 
gram involving a TTY remote device. 


The program processes eight message groups before terminat-— 
ing. It first issues four data messages to the remote terminal 
and to the operator terminal. It issues the write requests from 
alternate data buffers to ascertain the status of the interfaces 
among the file system, FORTRAN Compiler, and the communications 
subsystem. When the four initial message groups are complete, 
the program requests input data from the operator terminal. 


After the operator enters a message, the operator terminal 
displays the message and an acknowledgment message. When the 
fourth message is received, the application program terminates. 


Every input message, which is preceded by a blank or NUL 
character that is not displayed, may have up to 59 ASCII 
characters. 


The system continually monitors the status register, dis- 
playing error condition codes or status messages on the operator 
terminal. For example, a condition indicating no data available 


(buffer busy) at the remote device, lasting more than 20 seconds, 


causes a Status return code of 516,, . The program continues the 
read attempt since that status is not an error condition. The 

read statement is issued only after a status code 0,, 
to indicate that data is available (buffer not busy). 


is returned 


A i = 
ABB ES 
ai : 


FORCLS GCOS6-1 FORTRAN RFV: 0101 D 1977/04/20 1540:00.3 PAGE: 02 


44ac 

45 C NUTPUT MESSAGES TO REMOTE DEVICE CLFN 9) 
46 C 4 MESSAGES ISSUED TO DEVICE AND LFNG 

47 C FROM ALTERNATING ABUFFERS 

48 C 


49 70 WRITE (9,80)CW3,N 
50 AN FORMAT(1X,A48&,T2) 


S51 WRITE(4,80)CW3,N 

S2 GO TO 20 

53 90 WRITE(9,80)CW4,N 

S54 WRITE(4,80)CW4,N 

SS IF(N .EQ. 4) GO TO 15 

56 GO TN 20 

S7 C 

Sa C INPUT FROM REMOTE NEVICE (LEN A) 

59 C 4 MESSAGES ALLOWFD 

60 C | | | 
61 C SPACE 1 CHARACTER AND TYPE. UP TO S9 CHARACTERS 
62 C FOLLOWED BY A CARRIAGE RETURN 

63 C TYPE SECOND MESSAGF WHEN DEVICE TYPES 

64 C "MESSAGE x RECN" 

65 C 


66 100 READ(A,110)CRI 
67 110 FORMAT(1X,A0A1) 


68 WRITE (4,110)CRI 

69 112 CALL 7FSTOT(9,TSTAT) 

70 IFCISTAT .FQ, 0)GO TN 114 
71 GO TO Ite 


72 114 WRITE(9,115)N 
73 #4115 FORMAT(1X,'MESSAGF ',Te,* RECD') 


74 IF(N .NE, AGO TO 20 
75 GN TO 130 ~ 

76 120 READ(A,110)CRO 

77 WRITE(4,119)CR2 

78 121° CALL ZFSTNT(9,ISTAT) 

79 IFCTSTAT .EQ, 0)GN TO 125 
80 GO TO 121 

&®1 125 WRITE(9,11S)N | 

82 IF(N .NE. 8)60N TO 20 

83 C | 

84 C CLOSE UNITS ANN -EXTT 

AS C 

86 130 CALL ZFSTOT(9,ISTAT) 

87 IFCISTAT .FQ. 0) GO TO 140 
88 GO TQ 130 

89 140 CLOSECUNTT=8) 

90 CLOSE (UNI T=9) 

91 STOP 

92 END 


0 DIAGNOSTICS 


Figure D-3. FORTRAN Application Example for TTY 
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 FORCLU 


Omnro er NOWW = 


10 


AOACE 


AAANAMANANAANAAN 


1S 


20 


2s 
30. 


40 


So 


60 


GCNShe1 FORTRAN” REV: 0101 DY 1977/04/20 1540:00.3 PAGE: 01 


FORTRAN COMMUNICATION PROGRAM = FORCL4 
ILLUSTRATES USE MF ZFSTIN AND ZFSTOT 


WRITES 4 MFSSAGES TO THE OPERATOR'S TERMINAL (LFN 4) 
ANN SEND TO A REMOTF NEVICE CIF. TTY) ON LFN 9 VIA MLCP 
FOLLOWED RY A-RFAN OF 4 MESSAGES FROM THE SAMF REMOTE 
DFVICE (IE. TTY) ON LFN A, ALL MESSAGES ARF NISPLAYED 
ON THE OPERATOR'S CONSOLF, AND RECEIVED MESSAGES ARE 
ACKNOWLEDGED ON THE REMOTE NEVICE 
DEVICF STATUS IS REPORTEN USING, 

CALL 7ZFSTINCI,J) FOR INPUT, AND 

CALL ZFSTOT(I,J) FOR OUTPUT. 


PROGRAM FORCI.4 

CHARACTER *48 CW3,CW4 

CHARACTER CR1(60),CR2(60) 

NATA CW3/'THIS ITS COMM, OUTPUT TO THE TTY = MESSAGF NUMBER'/ 


J 
Ni 
K = 
Cw4a = Cw3 
OPENCUNTT=A) 
OPENCUNTT=9) 
GO TO 20 

K s AB 


oo > 


CHECK COMMUNICATION DEVICE STATUS 
USING ZFSTIN OR ZFSTOT ROUTINE 


N=s=N ¢# 1 

J= 0 

IFCK .EQ.A)CALL ZFSTIN(K, ISTAT) 

TFECK.FQ.9O)CALL ZFSTOT(K,ISTAT) 

IFCISTAT .EQ. 0) GO TO (70,90,70,90,100,120,100, 120), N 
IFCTSTAT = §$16)50,40,50 

JsJ+i 

IF(J .LT. 10000) GO TO 30 

WRITE(4,60)N,ISTAT . 
FORMAT(1X,'STATUS RTN MESSAGE NO.',I2,' STATUS TYPE',I4) 
IFCISTAT .EQ. $16) GO TO 25 

GO TO 140 


Figure D-3 (cont). FORTRAN Application Example for TTY 
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Assembly Language Example for TTY or VIP Using Physical I/0 


Figure D-4 shows an assembly language source program 
(SENDER), uSing Physical I/O, that tests TTY or VIP terminals by 
sending character strings to the terminals. 


The user enters SENDER 07 to test a TTY terminal, or SENDER 
OA to test a VIP terminal. The values 07 and OA are the logical 
resource numbers (LRNs) of the TTY and VIP, respectively. 


The program will halt on the first instruction, and will 
continue when the Execute button 1S pressed. 
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title sender 

® 
Libm exec lib 
xdef sender 

* 

sender hit 
ldv $r30 
idr S$r7eot$b7 
cmv $r7o2 
bl >+$a 
ldb S$b6e+$b7 
tdr $r6e4+$b6 
idb $b5-+$b7 
idr $r5etSb5 
idv $ris2 
cmv $r5e2 
bg exit 
(dv $r1,0 
tlh $ri-$b5.$r1 
dh $r3e<tabe$ri 
blz S$rsSrsexit 
ldv $rioi 
aun Sr ied0dedt 1 
idh $ris<tab.$ri 
blz $risexit 
so | $r304 
or $r3,=$r1 

$a ldv $r4e—-14 | 
lab $b4,i10rb00 

$b : sth $r3e$bD4.$afe! 
SRQIO, 
nop >$+2 
bnez S$rilermexit 
lab S$O4,$bD4.Safrx2+6 
bine $r4e>-$b 
ldv $r1.0 

exit ldr $r2e=$ei 
STRMRQ, 

& 

yorb00 resv S$af-0 
dc x*Q1° 
dc x'Oa' 
resv S$af,0 
dc 0 
dc 0 
dec 0 
dc 0 

iorb20 resv $af-0 
de x°41° 
dc x"41° 
de <msg20 
dc 43 
de x*20° 
dc 0 

| dc 0 

iorb28 resy $af.0 
dc x°41° 
dc x41! 


Figure D-4. 


Assembly Language Example for TTY or VIP 


Using Physical I/0 


.D-20 


$r3 <- default irn. 
$r7 <- parameter count 


test parameter count < 2 


($b6 <- a(p1 char count) 


$r6 <= pl char count 


$b5 <- a(p2 char count). 


$r5S <= p2 char count 
$r1<- 2 = invalid Irn 
test char count > 2. 


$ri<- 0 
$ri<- ist char (ascii) 
$r3 <- Ist char (Chex) 
test for bad char 
$ri<- 1 

Srt <- ¢nd char Cascais 
$r1l <= 2nd char Chex) 
test for:‘bad char 

$r3 <- $73%*16 

$r3 <- hex (Irn 

$r4 <= iorb count 

$b4 <= alist iorb) 

$r3 -> Irn 


trace 

test for error 

$b4 <- al(next iorb) 
test iorb count = o 
$r1<-0 = success 

$r2 <- error code 


CBO3 


x Bit 
aa oN 


= 


iorb30 


iord38 


torb40 


iorb48 


iorbS0 


1orb58 


iorbé60 


Figure D-4 (cont). 


Assembly Language Example for 
Using Physical I/0 
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TTY or VIP 


CBO3 


i0rb68 resv S$af0 


dc x'41° 
dc x°41° 
dc <msg68 
dc 43 
dc x*20° 
dc 0 
dc 0 
iorbd70 resv gaff 0 
dc x*O1' 
dc x'41° 
dc <msg70 
dc 43 
dc x 20° 
dc 0 
. dc 0 
iorb78 resv $af0 
dc — we 418 
dc x'418 
dc <msg/78 
dc 43 
dec x*20° 
dc 0 
dc 0 
TOrOss resv dalteu 
de xO 
dc x'Ob' 
resv gaf,0 
dc 0 
dc x'Q3° 
dc 0 
dc 0 
msg20 dc x'42° 
text 120 21 22 23 24 25 26 27 . 
dc 2° 202020202120222023202420252026202720' 
msg28 dc x "41° 
text °28 29 2A 28 2C 20 2E eF ° 
dc 2'2020282029202a202b20 2c 202d202e202fF20' 
msg30 dc x°47% 
text *30 31 32 33 34 35 36 37 ° 
. de ET coc Op Ue aleUecresn ce menaeoneener ge 
msg38 dc x "41° 
text 438 39 3A 38 3C 30 3€ 3F , 
dc z*2020382039203a203b20 3c 203d20 3e203F 20" 
msg40 dc x°41° 
text 140 41 42 43 44 45 46 47 é 
dc 2° 202040204120422043204420452046204720' 
msg48 dc arte 
text "48 49 4A 48 4C 4D GE 4F & 
dc | Z2*2020482049204a204b204c204d204e204F20' 
msg5S0 dc x41? 
text "50 $1 52 53 54 55 56 5? ° 
dc Bee OCU o Neue lenge ren sere comeney: 
msg58 de x°41! 
| text | 158 59 SA 5B 5C.50 SE SF ‘ 
dc z2*2020582059205a 205b20 5c 205d20 Se205f20° 
~msg60 dc tate 
text "60 61 62 63 64 65 66 67 ° 
dc 2 *20206020612062 20632064 2065 2066206720" 
msg68 dc x*41° 
text 168 69 6A 68 6C 6D 6E 6F ° 


Figure D-4 (cont). Assembly Language Example for TTY or VIP 
Using Physical I/0 
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Figure D-4 


(cont). 


2'°2020682069206a206b206c206d206e206f 20° 


x°41° 


*70 71 72 73 74 75 76 77 


z°202070207120722073207420752076207720° 


x'41° 


°78 79 7A 78 7C 7D 7E 7F 


2°2020782079207a207b207c207d207e207F 20° 


z*80808080' 
2*80808080' 
2*80808080' 
z*80808080' 
z*80808080' 
z*80808080' 
2*80808080° 
z'80808080! 
z*80808080' 
z'80808080° 
z'80808080! 
z'80808080' 


2'00010230° 


z'04050607' 


z'08098080° 


z*80808080° 
z2'800a0b0c* 
z'Od0e0Df80° 
z'80808080° 
z'80808080° 
z*80808080' 
z*80808080° 
z'80808080'° 
z°80808080' 
z*800a0b0c" 
z*Od0e0f 80° 
z*80808080' 
z*80808080° 
z*80808080° 
z'°80808080'° 
z°80808080' 


2°80808080° — 


senderssender 
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00 
04 
08 
OC 
10 
14 
18 
TC 
20 
24 
28 


02 
06 
OA 
OE 
12 
16 
1A 
TE 
22 
26 
2A 
2E 


32. 


03 
07 


Assembly Language Example for TTY or VIP 
Using Physical I/O 


CBO3 


| 
| 
\ 
\ 
| 
i 


sets, 


APPENDIX E 


ASCII AND EBCDIC CONTROL CHARACTERS AND CHARACTER SETS 


Tables E-l and E-2 illustrate the ASCII and EBCDIC character 


respectively. 


In addition to the ASCII characters, 


Table 


E-1 shows the hexadecimal equivalents; Table E-2 shows the binary 
and hexadecimal equivalents of the EBCDIC character set. 


Following are lists of the control characters and special 
graphic characters that appear in the two tables: 


CONTROL CHARACTERS 


Acknowledge 
Bell | 
Backspace 
Bypass. 

Cancel 

Cursor Control 
Carriage Return 
Customer Use l 
Customer Use 2 
Customer Use 3 


Device Control 1 
Device Control 2 
Device Control 3 
Device Control 4 
Delete 


Data Link Escape 
Digit Select 

End of Medium 
Enquiry 

Eight Ones 

End of Transmission 
Escape 

End of Transmission Block 
End of Text | 
Form Feed 

Field Separator 
Graphic Escape 
Group Separator 
Horizontal Tab 


File Separator 
Group Separator 


Interchange 
Interchange 
Idle 
Interchange 
Interchange 
Lowercase 
Line Feed | 
Negative Acknowledgment 
New Line 

Null 

Punch Off 

Punch On 

Restore 

Reverse Line Feed 
Reader Stop | 

Shift In 

Set Mode 

Start of Manual Message 
Shift Out | 

Start of Heading 

Start of Significance 
space 

Start of Text 
Substitute 

Synchronous Idle 

Tape Mark 

Uppercase 

Unit Separator 

Vertical Tab 


Record Separator 
Unit Separator 


CBO03 


OPECIAL GRAPHIC CHARACTERS 


¢ Cent Sign > Greater-than Sign 
. Period, Decimal Point ? Question Mark 

< Less-than Sign \ Grave Accent 

( Left Parenthesis : Colon 

+ Plus Sign # Number Sign 

, Logical OR @ At Sign 

& Ampersand ' Prime, Apostrophe 
! Exclamation Point = Equal Sign 

S$ Dollar Sign "Quotation Mark 

* Asterisk e TT Lae 

) Right Parenthesis { Opening Brace 

> Semicolon Uw’ Hook 

— Logical NOT W Fork 

- Minus Sign } Closing Brace 

J Slash \ Reverse Slant 

| vertical Line d Chair 

, Comma | Long Vertical Mark 
$ Percent [ Opening Bracket 
— Underscore ] Closing Bracket 


Circumflex 


Table E-l. 


an 
S 
Z 
eo 
- 
i 


z 
& 
a 
eo 
| 
wD 
° 
= 
by 
ag 


: Q| sy te 
#/8|a|3|5|5/5 


ASCII/Hexadecimal Character Equivalents 
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EBCDIC/Hexadecimal/Binary Character Equivalents 


Table E-2. 


Cie IBit Positions 2,3 


3 
ben 
vo 
- 
Y 
J 
b= 
Ss 
x= 
1?) 
oS 
fore) 
[ 


4 


{This character is not supported in the 


CB03 


APPENDIX F 


DEVICE-SPECIFIC CONTROL CHARACTERS 


This appendix lists the nonalphanumeric control characters 
for devices supported by the communications subsystem. 


NOTE: A slash between two characters indicates that both 
keys are pressed simultaneously, e.g., CTRL/H indi- 


cates that the CTRL key and H key are passed at the 
Same time. 


Table F-l. TTY Nonalphanumeric Control Characters 


Hexadecimal 
Character Value Function Key Strokes 


Answer back CTRL/E 
Ring Bell CTRL/G 


Backspace (nondestructive CTRL/H 
cursor backward) | 


Line feed CTRL/J 
Form feed (clear screen) CTRL/L 
Carriage return CTRL/M 


Nondestructive cursor CTRL/R 
forward 


Space CTRL/P or 
Space bar 


NOTES: In a terminal with lowercase capability, 
uppercase characters require the use of 
the shift. 


DC2 iS an option for VIP 7100/7200 only. 


F-1 | CB03 


Table F-2. 


Character 

BS 08 
HT 09. 
LF OA 
FF OC 
CR OD 
DC1l 11 
DC2 12 
DC3 13 
DC4 14 
ESC 1B 
FS 1C 
GS 1D 
SP 20 

SE 


Backspace. 
Horizontal tab. 
Line feed. 


Form feed. 


Carriage return. 
Reverse line feed. 


Forward space 
(nondestructive 
cursor forward). 
Defines next two 
characters as line 
character position. 


Page return. 


First of several 


2-character 
sequences used for 
VIP control. 


First character of a 
2-character Sequence 
to define beginning 
of a fixed field. 


Defines start of 
variable field. 


space. 


Defines Start of 
blank field. 


VIP Nonalphanumeric Control Characters 


| Hexadecimal | 
Value . Function 


Key Strokes 
CTRL/H 
CTRL/I 
CTRL/J or LINE FEED. 
CTRL/L | 
CTRL/M or RETURN 
CTRL/Q 


CTRL/R 
CTRL/S 


CTRL/T 


! 


CTRL/P or space bar 
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Table F-3. BSC Nonalphanumeric Control Characters 


Hexadecimal | 
Character Value eek ae Ree Strokes 


Nontransparent  enepaienorenc Gace CTRL/@ 


Nontransparent data; CTRL/A 
last record of file | 


Transparent data CTRL/B 


Transparent data; last CTRL/C 
record of the File 


Table applies only to advanced data transmission 
mode, and describes control byte for line control. 


The control byte is neither sent nor received over 
the line. 
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APPENDIX G 


DUMP ROUTINE (DUMCP) FOR MULTILINE COMMUNICATIONS 
PROCESSOR (MLCP) 


The Honeywell program DUMCP, which is provided in source and 
object format, dumps the contents of memory (all or part) of the 
multiline communications processor (MLCP). DUMCP has the follow- 
ing functions: 3 

o In the dump, shows formatted lists of line control 

tables, communications control blocks, and communications 
channel programs. 


o Can print the dump on the operator terminal, line 
printer, or serial printer. 


o Can be used by the programmer for: 
- Aid in debugging application programs 
- Documenting problems 


- Pinpointing hardware, software, or firmware 
‘difficulties 


DUMCP cannot run in the batch task group ($B). 


DUMCP uses one MLCP channel to transfer dump data from the 
MLCP to main memory (in block-mode read). The user must there- 
fore specify that MLCP channel and the channel of the output 
device that will produce the dump. 


LINKING THE BOUND UNIT CONTAINING DUMCP 


The bound unit that contains DUMCP can be invoked in either 
of two ways: | 


o It may be loaded and activated as a self-contained unit, 
by the operating system. 
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o It may be activated by the application program, at one of 
three starting locations, when the application is linked 
with DUMCP. 


Linking DUMCP as a Self-Contained Bound Unit 


To execute the bound unit that contains only DUMCP, the user 
must load the Linker (with the LINKER command), specifying the 
following Linker directives (See Program Execution and Checkout 
manual): 


SYS 


(Optional) Designates that the bound unit can be a 
System task in the system task group. 


LINKN DUMCP 


a —_— 


Requests that the object bound unit DUMCP be Linked. 
VDEF RDMLCP, X'nnnn' 


Designates nnnn as the MLCP channel for block-mode 
read. | 


VDEF DMPOUT, X'nnnn' 


Designates nnnn as the channel number of the device 
where the dump is to be printed, which must be an 
operator terminal, line printer, or Serial printer. 


MAP 
Requests a link map. 
QUIT 


Terminates execution of the Linker when the bound unit 
has been created. 


NOTES: 1. More than one bound unit may be linked, . each 
| with itS own unigue name, depending on the type 
of system and on the MLCP channel to be used for 
the dump routine. 


2. When the purpose of the dump is to diagnose a 
channel error, that channel (value nnnn) should 
not be designated to be used by the dump 
routine. 
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Example: 


In this example, a linked version of DUMCP is placed on the 
volume Z10107. First the working directory is changed to 
one that contains the object module DUMCP.0O; then the Linker 
is called, according to the Linker directives shown below: 


CWD ~Z10107>SOURCE 
LINKER DUMCP -COUT >SPD>LPTO0O -SZ 8 


The user need not specify a relocation base or start 
address. The bound unit can then be executed. 


Any error will result in an error message, and/or error 
code, issued at execution time to the operator terminal. The_ 
System Messages manual describes DUMCP error messages. 


Linking DUMCP With the Application Program 


Either of the following methods can be used to specify 
values for the dump output device and for the block-mode read 
channel that will transfer dump data from the MLCP to main 
Memory : : 


1. Add the following assembly language XDEF external label 
definition statements to the Source module DUMCP.P: 


XDEF (DMPOUT,Z'nnnn' ) 
nnnn designates the channel of the output device 
XDEF (RDMLCP,Z'nnnn') 
nnnn designates the block-mode ead channel, 
or 
2. During linking, specify the following VDEF directives: 
VDEF DMPOUT,X'nnnn' 


The value nnnn designates the channel of the output 
device. 


VDEF RDMLCP,X'nnnn' 


The value nnnn designates the block-mode read 
channel. 


When Linker directives are specified to create the bound 


unit, enter LINKN DUMCP to request that the object unit DUMCP be 
linked. | 
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After DUMCP is linked to the application, the dump routine 
can be entered in any of three ways (described below) according 
to whether the entry point is specified as STRTDO, STRTD1 or 
STRTD2. | 


In any case, the application must include an XLOC (define 
external locations) instruction; i.e., XLOC STRTDO, XLOC STRTD1 
XLOC STRTD2. | 


STRTDO ENTRY POINT IN USING DUMCP 


When entry point STRTDO is used, DUMCP will halt at first 
entry. The user must then set certain register (see below) 
through the control panel before execution of DUMCP is resumed. 
These register values override the channel numbers specified in 
the source program or when DUMCP was linked with the application. 


NOTE: Register values for dumping the DLCP (dual line com- 


aes ayes ain an sao a eat clams 
munications processor) of the Model 23 Central 


Processor are shown separately. 


Register Value to be Entered 
SR4 Channel number of dump output device 
SR5 Channel number used for block-mode read 


SR6 0000; or first memory address of area 
to be dumped | 


SR7 OFFF (13FF for Model 23); or the last 
memory address of area to be dumped 


SB5 Return address. If no value is entered, 
| default is that the current address is 
returned to the system. 


The values in the registers control the contents of the 
dump, as shown in Table G-l. 


The format of the entry to specify entry point STRTDO is: 
JMP <STRTDO 

The dump routine dumps the MLCP (DLCP) memory to the speci- 

-fied device. Register $R2 (Table G-2) indicates results of the 


dump. When the dump is completed, control returns to the appli- 
cation at the instruction pointed to by register $B5. 
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STRTD]1 ENTRY POINT IN USING DUMCP 


When uSing entry point STRTDI1, the user must set certain 
registers (see below) before starting to execute the dump. These 
register values override the channel numbers specified in the 
Source program or when DUMCP was linked with the application. 


NOTE: Register values for dumping the DLCP of the Model 
23 Central Processor are shown separately. 


Register Value to be Entered 
SR4 Channel number of output device for the dump 
SR5 Channel number used for the block-mode eae: 
SR6 0000; or the first memory address of area to 
be dumped 
SR7 OFFF (13FF for Model 23); or the last 


memory address of area to be dumped 


The values in the registers control the contents of the 
dump, as shown in Table G-l. 


See Figure G-l for detailed example of dump formats and 
contents. : 
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Table G-l. Register Values and DUMCP Dump Contents 


Register and Contents Resulting Dump Contents — 


SR6 0000 Fully formatted dump, comprising line con- . 

SR7 OFFF trol tables, communications control pro- 
13FF grams, and communications control blocks 
(Model 23) | | 


SR6 0000 | Line control tables only 
SR7 O1FF 


SR6 OEOO | Communications control blocks only 
SR7 OFFF 
(Model 23) 
SR6 1200 


VAtormat ec Gums M within the 


eA ke te 


addresses (byte a specified in 
SR6 and $R7 


(Model 23) 


Less 
than: 
OFFF 
13FF 
(Model 23) 


The format of the entry specifying entry point STRTD1 is: 
LNJ SB5,<STRTD1 


The dump routine immediately dumps MLCP (or DLCP) memory to 
the specified device. The contents of SR2 (see Table G-2) will 
indicate a successful dump or an error condition. When the dump 
is completed, control returns to the application program at the 
instruction pointed to by register SB5. 
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ite, 


Table G-2. Register $R2 at Dump Execution - DUMCP 
Linked to Application 


Register SR2 
Contents Meaning 


Dump successfully completed; no errors. 


Invalid MLCP channel numbers. 


Device other than operator terminal or 
Serlial/line printer specified as the 


output device. 


STRTD2 ENTRY POINT IN USING DUMCP. 


STRTD2 should be used when the block-mode read channel 
(RDMLCP) and the output-device channel number (DMPOUT) values, 
Specified in XDEF statements or in Linker VDEF directives (See 


above) are to be used without change. Registers need not be 
changed prior to the dump request. 


The format of the entry specifying entry point STRTD2 is: 
LNJ  $B5,<STRTD2 | 


The contents of register SR2 (see Table G-2) will indicate 
succesSful dump or an error condition. 


When the dump is completed, control returns to the applica- 
tion program at the instruction pointed to by $B5. 


DUMCP DUMP FORMATS 


Formatted dumps of the MLCP comprise the following areas, 
whose formats are shown in Figure G-l below. 


o Line control table (LCT) area, byte locations 0000 
through O1FF. The LCT has 64 bytes, each shown in eight 
groups (four for Model 23) for eaSier reading. 


o Channel control program (CCP), byte locations 0200 


through ODFF (11FF for Model 23). The format shows 16 
bytes per line for eaSier reading. 
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Communication control block (CCB) area, byte locations 
OE00 through OFFF (1200 through 13FF for Model 23). 

There are four CCBs per channel. CCBs 0 through 3 are 
for the receive channel, CCBs 4 through 7 for the send 
channel. The dump shows the address, range, control 
byte, and status for each CCB. An R following an address 
indicates that the address field refers to the right byte 
of a word. When there is no R following the address, the 
the address refers to the left byte. 


NOTE: CCBs are used in the following order: For the 
receive channel, CCB 1 is used first, CCB 0 used 
last. For the send channel, CCB 5 is used first, 
CCB 4 used last. | 


DUMCP PROGRAMMING 


The following DUMCP programming considerations apply: 


Ee 


The application source program contains a macro call, 
making it necessary to preprocess the source through 
EXEC LIB when reassembly is required. 


When possible, use an inactive MLCP channel for the 
block-mode read channel, because the channel specified 
will be initialized and corresponding channel control 
block list reset. | 


To allow variations of RDMLCP and DMPOUT values, it may 
be convenient to line more than one iteration of the 
dump, with different names. 


When a printer whose channel number was deSignated is 
not ready or is disabled, the DUMCP program loops until 
the printer's READY button is pressed. 

DUMCP does not provide trap handling. 

DUMCP executes at interrupt level 3. Therefore, its 


execution preempts all system activities including clock 
functions. : 
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MCP DUMP REV 3 


RAM READ FROM CHAN. FC 


LCT 
0000 
0001 
0002 
0003 
0004 
0005 
0006 
0007 
0008 
0009 
0010 
0011 
0012 
0013 
0014 
0015 
0016 
0017 
0018 
0019 
0020 
0021 
0022 
0023 
0024 
0025 
0026 
0027 
0028 
0029 
0030 
0031 
0032 
0033 
0034 
0035 
0036 
0037 
0038 
0039 
0040 
0041 
0042 
0043 
0044 
0045 
0046 
0047 
0048 
0049 
0050 
0051 
0052 
0053 
0054 
0055 
0056 
0057 


LINO 


LIN! LIN2 

FC 00 
00 00 
£6 v0 
00 00 
00 00 
02 00 
53 00 
Bi 00 
00 00 
00 00 
30 00 
00 00 
00 00 
OE 00 
00 00 
00 00 
00 00 
00 00 
FS 00 
S6 00 
B2 00 
00 00 
D0 00 
03 00 
06 00 
Be 00 
06 00 
86 00 
00 00 
00 00 
00 00 
17 00 
FC 00 
00 00 
E6 00 
00 00 
00 00 
00 00 
82 00 
2C 00 
00 00 
00 00 
00 00 
00 00 
00 00 
OE 00 
00 00 
00 00 
AO 00 
00 00 
43 00 
44 00 
00 00 
82 00 
60 00 
OA 00 
06 00 
76 00 


Figure G-1. 


LINS 
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LING 


LINS 


00 


DUMCP Dump Example 


LIN6 


LIN? 
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0550 S51 10 90 
0560 09 EO 95 
0570 07 #%SO 10 
0580 01 jA2 S82 
0590 51 iF SO 
0SA0 El 03 #€E0 
0580 EA EQ AF 
0SC0 92 00 €E1 
0500 EO 09 O01 
05E0 S51 11 40e 
OSFO Ei 03 €E0 
0600 EO 09 €0 
0610 01 50 3A 
0620 92 7C €1 
0630 —E1 3A €0 
0640 19 S51 IF 
0650 B6 90 05 
0660 Si 10 90 
0670 00 $1 £410 
0680 84 82 00 
0690 00 00 OO 
06A0 00 00 00 
we ALL ZEROS «x 
06C0 00 00 O00 
0600 31 00 900 
we ALL ZEROS x* 
CCB AREA 
CcB ADDRESS 
LINE 0 
0000 000000 
0001 0057A7 
0002 003E71R 
0003 _ 000000 
0004 0O045E9 
0005 0045C3 
0006 0045F9 
0007 OO6FF7 
LINE 1 
0000 000000 
0001 003E98R 
~—6- 0002 OO06DF3R 
0003 000000 
0004 000000 
0005 000000 
0006 000000 
0007  +°(000000 
LINE Pe 
0000 000000 
0001 000000 
000e 000000 
0003 000000 
0004 000000 
0005 000000 
0006 000000 
0007 000000 
LINE 3 
0000 000000 
0001 000000 
000e 000000 


Figure G-l (cont). 


RANGE 


0000. 


O1F4 
0000 
0000 
0000 
0000 
0000 
0000 


0000 
0000 
0001 
0000 
0000 
0000 
0000 
0000 


0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 


0000. 


0000 
0000 


CONTROL 


STATUS 


0000 
OO00E 
1000 
0000 
1000 
1000 
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97 
ic 
92 
Fi 
Ei 
B9 
iF 
55 
50 
50 
51 
51 
92 
50 
19 
82 
50 
FF 


84 


00 


86 
00 


05 
00 


DUMCP Dump Example 


EO 
Fi 
09 
F9 
02 
E0 
3A 
00 


40. 


FF 
Bo 
F3 
36 
02 
E1 
EO 
02 
90 
84 
00 


00 
00 


50 
00 
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04B0 
04C0 
0400 
04E0 
O4F 0 
0500 
0510 
0520 
0530 
0540 


00 00 
00 00 
00 00 
16 00 
06 00 
C6 00 
00 51 08 
7C £€O 17 
23 51 24 
0B £0 09 
EQ E7 EO 
92 FF €1 
62 01 #42€E€0 
60 01 SO 
10 €1 10 
EO 71 €0 
01 EO €E4 
Se 3C €1 
90 1F 61 
S0 37 92 
FO 25 90 
63 01 €E0 
EO 95 £0 
SO 24 60 
92 80 02 
01 62 O1 
E7 S50 37 
37 56 3E 
80 S51 30 
FF E1 07 
e—& 50 30D 
32 «€O) 16 
EO F2 90 
S56 18 E0 
EO OD S¢ 
SO 3A 92 
F2 69 50 
FO SF £0 
56 1A FO 
FO 63 50 
O1 Ae St 
FO 67 €E0 
04 93 TF 
EO 49 €E0 
92 FF Fi 
Fl AF £0 
Fi DD €0 
16 51 1D 
EO €3 €E0 
SO 1D 92 
94 80 S51 
S1 10 €E0 
90 O1 11 
EO E3 €E0 
Fo 55 51 
50 1D 92 
E1 OE 92 
10 94 80 
E1 0S 90 
Figure G-l 


00 00 00 00 00 
00 00 00 00 00 
00 00 00 00 00 
00 00 00 00 00 
00 00 00 00 00 


(cont). DUMCP Dump Example 
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0003 
0004 
0005 
0006 
0007 
LINE 
0000 
0001 

0002 
0003 
0004 
0005 
0006 
0007 
LINE 
0000 
0001 

0002 
0003 
0004 
0005 
0006 
0007 


LINE 
0000 
0001 
0002 
0003 
0004 
0005 
0006 
0007 
LINE 
0000 
0001 
0002 
0003 
0004 
0005 
0006 

0007 


END OF MCP DUMP 


000000 
000000 
000000 
900000 
000000 


000000 
000000 
000000 
000000 
000000 
000000 
000000 
000000 


000000 
000000 
000000 
000000 
000000 
000000 
000000 
000000 


6 


000000 
000000 
000000 
000000 
000000 
900000 
000000 
000000 


000000 
000000 
000000 
000000 
000000 
000000 
000000 
000000 


0000 
0000 
0000 
0000 
0000 


0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 


0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 


0000 
-0000 
0000 
0000 
0000 
0000 
0000 
0000 


0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 


Figure G-1 (cont). DUMCP Dump Example 
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